Дизайн нереляционной базы данных для хранилища больших данных - PullRequest
Новая
       109

Дизайн нереляционной базы данных для хранилища больших данных

0 голосов
/ 11 июля 2020

Предположим, мне нужно создать таблицу для Spotify, в которой мне нужно быстро получить, какие элементы (песня или альбом) уже приобрел пользователь, чтобы она могла воспроизводиться для пользователя. Сценарий прост: когда пользователи нажимают, чтобы купить песню, базе данных необходимо быстро обновить конкретную купленную песню в учетной записи пользователя. экспоненциально, с другой стороны, формат доступа довольно прост и исправен, нереляционная база данных предназначена для этого варианта использования. Вот почему я думаю об использовании HBase, Cassandra или MongoDB.

Я хотел бы использовать UserId в качестве первичного ключа для этой таблицы покупок, будут ли магазины с широкими столбцами, такие как (HBase или Cassandra), или базы данных документов, такие как MongoDB работать лучше для этого сценария?

Входные данные - это просто user_id и ответ таблицы базы данных со всеми доступными приобретенными элементами. Какова лучшая стратегия создания таблиц базы данных? 

{user_id:int
   {purchased_item: item1
                    item2
                    item3
   }
}

Вторая таблица будет использоваться для поиска определенных c исполнителей, альбомов, жанров и песен, доступных для покупки.

Будем признательны, если вы можете поделиться примерами передовой практики из реального приложения. Или любую хорошую статью / документ / блоги, которые я могу прочитать.

1 Ответ

1 голос
/ 12 июля 2020

Если вы рассматриваете возможность работы в режиме, близком к реальному времени, я бы определенно рассмотрел возможность использования Cassandra, особенно для подробного хранения истории! uuid, buy_id uuid, item_id uuid, item_details text, item_name text, time_of timestamp, PRIMARY KEY ((user_id), Purchase_id, item_id));

Это позволит вам сгруппировать данные несколькими способами, сначала используя user_id, затем используя Purchase_id, чтобы сохранить все товары, записанные для каждой покупки!

Имея первичный ключ, сформированный из ключа раздела, user_id, ключа кластеризации, Purchase_id и item_id, мы можем сгруппировать товары в Purchase_id, а затем в user_id.

https://cassandra.apache.org/doc/latest/data_modeling/intro.html https://docs.datastax.com/en/landing_page/doc/landing_page/current.html

...