Каталог продукции - Магазин документов или Семейный магазин Column
Хотите знать, какая технология будет лучше для типичного каталога продукции интернет-магазина. Я пишу магистерскую диссертацию о nosql в корпоративной среде и думаю, что долго буду думать о хранилищах документов. Прочитайте много статей, которые рекомендуют хранилища документов из-за его гибкости, которая необходима для моделирования тысяч различных продуктов. Но, насколько я знаю, магазины семейства колонн, такие как Cassandra, предлагают такую же гибкость.
Что мне больше всего нравится в использовании cassandra, так это то, что nosql-database.org говорит об этом (отмечены наиболее интересные особенности):
Масштабируемое масштабируемое хранилище разделенных строк, архитектура без мастера, линейная производительность, отсутствие единичных точек отказа, поддержка чтения / записи в нескольких центрах обработки данных и облачных зонах доступности. Метод API / Query: CQL и Thrift, репликация: peer-to-peer, написано на: Java, параллелизм: настраиваемая согласованность, разное: встроенное сжатие данных, поддержка MapReduce, первичные / вторичные индексы, функции безопасности.
В конце я сосредотачиваюсь на создании прототипа высокодоступной и масштабируемой Multishop System, которая использует постоянство полиглота, например, K/V-хранилища для сессий, хранилище документов или хранилище семейства столбцов для каталога товаров и, возможно, RDBMS для инвентаризации / ценообразования, например Садаладж и Фаулер упоминаются в их книге "NoSQL Destilled".
Если возможно, предоставьте научные ответы или другие надежные источники для ваших ответов.
Спасибо!
2 ответа
Ахиллесова пята хранилища документов
Стюарт Хэллоуэй отметил, что хранилище документов - это самое большое решение для блокировки схем, которое слишком негибкое, с чем я согласен. Couch/Mongo и другие пытаются смягчить это, предоставляя обходные пути для создания вторичных признаков, способности и необходимости быть в курсе простых идентификаторов объектов и т. Д. И, конечно, если вы думаете о версии (то есть добавляете переменную "time" в вашу систему) хранилища документов быстро перестают обеспечивать плавную поддержку и путешествия во времени.
Колонка Store: проблема актуальности
Cassandra - это действительно убедительное решение для построения "масштабируемых"/"распределенных" систем с реальными примерами, такими как Netflix, где 500 узлов Cassandra могут быть запущены в AWS в течение нескольких минут, и все запросы попадают в кольцо Cassandra.
Однако, учитывая проблему, о которой говорится в вашем вопросе, Кассандра будет излишним излишним. Не только потому, что это немного сложнее, чем "другие", либо потому, что умственно сложнее создать надежную модель данных поверх магазинов, ориентированных на столбцы, но и потому, что проблема "каталога товаров" - не совсем ракетная наука. Это может быть, если вы захотите добавить машинное обучение позже, чтобы предсказать / распознать / и т. Д., Но сам каталог - нет, и более простые хранилища, такие как, например, PostgreSQL, решат это легко.
Простое желание NoSQL
Если вы действительно хотите использовать NoSQL для каталога продуктов, я бы определенно рассмотрел 3 решения для вашего прототипа:
- Riak как "K/V для сессий"
- Datomic для решения "Каталог продукции, инвентарь и цены"
- В зависимости от размера и характера проблемы и окончательного решения, я хотел бы рассмотреть Redis для кэширования этих сессий, при этом Datomic удобно размещается на Riak в качестве службы хранения.
Практика против теории
Два классических NoSQL документа, которые впервые сделали NoSQL звучащим на практике, - это Dynamo и BigTable. Я считаю Datomic следующим эволюционным шагом во вселенной БД, представляя гибридную модель данных с истинными признаками и связями без блокировки схемы и неизменяемости, из которой следует все: безопасное путешествие во времени, кэширование, локальные значения БД и т. Д.
Практически, если бы это не были основные тезисы, в зависимости от масштаба и определения реальной проблемы, я бы выбрал Datomic и PostreSQL для решения каталога, инвентаризации, ценообразования и т. Д.
Большим преимуществом Datomic здесь является путешествие во времени. На практике очень важно иметь возможность безопасно и легко сделать это в "Системе покупок".
Большим преимуществом PostgreSQL является его знакомство и доступность инструментов SQL для аналитики и отчетности.
К настоящему времени я думаю, что магазины семейства колонн не очень хорошо подходят для калорий продукции. Это потому, что продукты часто содержат некие коллекции, такие как теги, списки треков для музыкальных записей, разные размеры для одежды и так далее.
Кассандра поддерживает коллекции, но они не доступны для поиска! Это обязательная функция для тегов, например. В отличие от этого, например, MongoDb предлагает оператор $in для поиска во вложенных массивах...
Я не хочу сказать, что в Cassandra невозможно моделировать каталог товаров, но я думаю, что гораздо проще сделать это в хранилище документов.