Як думати в сховищах даних замість баз даних?

Як приклад, Google App Engine використовує для зберігання даних Google Datastore, а не стандартну базу даних. Хтось має поради щодо використання Google Datastore замість баз даних? Здається, я навчила розум на 100% думати в об'єктних відносинах, які відображаються безпосередньо на структурах таблиць, і зараз важко бачити щось інакше. Я можу зрозуміти деякі переваги Google Datastore (наприклад, продуктивність та здатність поширювати дані), але деяка хороша функціональність бази даних жертвується (наприклад, приєднується).

Хто-небудь, хто працював з Google Datastore або BigTable, має якісь корисні поради щодо роботи з ними?

Є дві основні речі, до яких потрібно звикнути про сховище даних App Engine, порівняно з "традиційними" реляційними базами даних:

• Магазин даних не робить різниці між вставками та оновленнями. Коли ви телефонуєте put () на сутність, ця сутність зберігається в сховищі даних за допомогою свого унікального ключа, і все, що має цей ключ, буде перезаписано. В основному, кожен тип сутності в сховищі даних діє як величезна карта або відсортований список.
• Запитання, як ви нагадали, значно обмеженіше. Ніяких приєднань, для початку.

Ключова річ - і причина обох цих відмінностей - це те, що Bigtable в основному діє як величезний упорядкований словник. Таким чином, операція put просто встановлює значення для даного ключа - незалежно від будь-якого попереднього значення для цього ключа, а операції з вилучення обмежуються вилученням окремих клавіш або суміжними діапазонами ключів. Більш складні запити можливі за допомогою індексів, які в основному є власними таблицями, що дозволяє реалізовувати складніші запити як сканування на суміжних діапазонах.

Після того, як ви поглинули це, у вас є основні знання, необхідні для розуміння можливостей та обмежень сховища даних. Обмеження, які могли здатися довільними, напевно, мають більше сенсу.

Ключовим тут є те, що, хоча це обмеження щодо того, що ви можете зробити у реляційній базі даних, саме ці обмеження - це те, що робить практичним масштабування до тієї величини, з якою розроблений Bigtable. Ви просто не можете виконати такий запит, який добре виглядає на папері, але жорстоко повільний у базі даних SQL.

З точки зору того, як змінити представлення даних, найголовніше - це попередній розрахунок. Замість того, щоб робити приєднання під час запиту, попередньо розраховуйте дані та зберігайте їх у сховищі даних, де це можливо. Якщо ви хочете вибрати випадковий запис, генеруйте випадкове число і зберігайте його з кожним записом. Там не ціла куховарська книга цих роду поради та хитрості тут Edit: Куховарська книга більше не існує.

Те, як я пішов про перемикач розуму, це взагалі забути про базу даних.

У світі реляційних db вам завжди доведеться турбуватися про нормалізацію даних та структуру вашої таблиці. Викопайте все це. Просто розмістіть свою веб-сторінку. Викладіть їх усіх. А тепер подивіться на них. Ви вже 2/3 там.

Якщо ви забули поняття про те, що значення розміру бази даних не повинні дублюватися, то ви там 3/4, і вам навіть не довелося писати жодного коду! Нехай ваші погляди диктують ваші Моделі. Вам не доведеться брати свої об'єкти і робити їх двомірними більше, як у реляційному світі. Ви можете зберігати предмети з формою зараз.

Так, це спрощене пояснення випробування, але це допомогло мені забути про бази даних та просто зробити заявку. Я поки що зробив 4 додатки App Engine, використовуючи цю філософію, і є ще багато.

Я завжди хизуюся, коли люди виходять - це не стосунки. Я написав cellectr в django і ось фрагмент моєї моделі нижче. Як бачите, у мене є ліги, якими керують або тренують користувачі. Я можу з ліги отримати всіх менеджерів, або від даного користувача я можу повернути лігу, яку вона тренерів або менеджерів.

Тільки тому, що немає конкретної підтримки зовнішніх ключів, це не означає, що ви не можете мати модель бази даних з відносинами.

Мої два пенси.

class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    

Я прийшов із світу реляційних баз даних, тоді я знайшов цю сховище даних. пішло кілька днів, щоб повісити його. добре, є деякі мої висновки.

Ви, мабуть, вже знали, що Datastore створений для масштабування, і саме це відокремлює його від RDMBS. щоб краще масштабувати великі набори даних, App Engine вніс деякі зміни (деякі означають багато змін).

RDBMS VS
Структура DataStore
У базі даних ми зазвичай структуруємо наші дані в Таблиці, Рядки, що в Datastore, вони стають видами та сутностями .

Взаємозв'язки
У RDBMS, більшість людей переслідує відносини «один на один», «багато в одного», «багато-до-багатьох», у сховищі даних, оскільки у нього немає речі «Не приєднується», але все ж ми можемо досягти нашої нормалізації за допомогою « ReferenceProperty ", наприклад, Приклад стосунків один до одного .

Індекси
Зазвичай у RDMBS ми робимо індекси, такі як Первинний ключ, Зовнішній ключ, Унікальний ключ та Індексний ключ, щоб прискорити пошук та підвищити продуктивність нашої бази даних. У сховищі даних вам потрібно зробити щонайменше один індекс на вид (він автоматично генерує, чи вам це подобається чи ні), оскільки сховище даних здійснює пошук вашої сутності на основі цих індексів і повірте мені, що це найкраща частина. У RDBMS ви можете шукати за допомогою неіндексне поле, хоча це займе певний час, але воно буде. У Datastore не можна здійснювати пошук, використовуючи властивість неіндексувати.

Граф
У RDMBS, набагато легше вважати (*) , але в сховища, будь ласка , навіть не думаю , що це в звичайному порядку (Так є лічильник функція) , оскільки вона має більш тисячі , і це буде коштувати стільки ж невеликий opertion як особи, це не добре, але у нас завжди хороший вибір, ми можемо використовувати лічильники осколків .

Унікальні обмеження
в RDMBS, ми любимо цю функцію, правда? але у Datastore є свій шлях. ви не можете визначити властивість як унікальну :(

Запит
GAE Datatore забезпечує кращу функцію LIKE (О, ні! У сховищі даних немає LIKE ключового слова) SQL, що є GQL .

Вставка даних / оновлення / видалення / вибір
Це там, де нас усіх цікавить, так як в RDMBS нам потрібен один запит на Вставити, Оновити, Видалити та Вибрати так само, як RDBMS, Datastore поставив, видалить, отримай (не надто хвилюйся), оскільки Datastore поставити або отримати з точки зору запису, читання, малих операцій (читання витрат на дзвінки в сховище даних ) та ось, де моделювання даних вступає в дію. ви повинні мінімізувати ці операції та тримати роботу програми. Для зменшення операції зчитування можна використовувати Memcache .

Погляньте на документацію Objectify. Перший коментар внизу сторінки говорить:

"Приємно, хоча ви написали це для опису" Objectify ", це також одне з найбільш стислих пояснень самого магазину аппендину, який я коли-небудь читав. Дякую."

https://github.com/objectify/objectify/wiki/Concepts

Якщо ви звикли думати про об'єкти, націлені на ORM, то в основному це працює сховище даних на основі сутності, наприклад, Google Engine App Engine. Щось таке, як приєднується, ви можете переглянути еталонні властивості . Вам не потрібно турбуватися про те, чи використовує він BigTable для бекенда чи щось інше, оскільки серверний контент абстрагується інтерфейсами API GQL та Datastore.

Те, як я дивлюся в сховище даних, вид ідентифікує таблицю, сама по собі, а сутність - це окремий рядок у таблиці. Якщо google мав би вийти з роду, ніж його просто одна велика таблиця без структури, і ви можете скидати все, що ви хочете, в сутність. Іншими словами, якщо сутності не прив'язані до виду, який ви майже можете мати будь-яку структуру для сутності та зберігати в одному місці (вид великого файлу, який не має до нього структури, кожен рядок має власну структуру).

Тепер повернемось до оригінального коментаря, зберігання даних Google і bigtable - це дві різні речі, тому не плутайте сховище даних Google із сенсом зберігання даних. Bigtable коштує дорожче, ніж bigquery (Основна причина, коли ми з ним не пішли). Bigquery має належні приєднання та RDBMS, як мова sql та його дешевше, чому б не використовувати bigquery. Однак, bigquery має деякі обмеження, залежно від розміру ваших даних, з яким ви можете або не стикаєтесь.

Крім того, з точки зору мислення з точки зору зберігання даних, я думаю, що правильним твердженням було б "мислення з точки зору баз даних NoSQL". У наші дні їх є занадто багато, але коли мова йде про продукти Google, за винятком хмарного SQL Google (який є mySQL), все інше - NoSQL.

Укорінившись у світі баз даних, сховище даних для мене було б гігантською таблицею (звідси і назва "bigtable"). BigTable - це поганий приклад, тому що він робить багато інших речей, які типова база даних може не робити, і все ж це база даних. Швидше за все, якщо ви не знаєте, що вам потрібно створити щось на кшталт "великої таблиці" Google, ви, ймовірно, будете добре зі стандартною базою даних. Вони потребують цього, оскільки вони обробляють божевільну кількість даних і систем разом, і жодна комерційно доступна система не може реально виконати цю роботу саме так, як може продемонструвати, що їм потрібно виконати цю роботу.

(посилання на велику таблицю: http://en.wikipedia.org/wiki/BigTable )