Нужен совет по выбору хранилища данных - PullRequest
Новая
       53

Нужен совет по выбору хранилища данных

0 голосов
/ 30 сентября 2018

Требования

Должен иметь

  • Горизонтально масштабируемый.
  • Быстрая сортировка по вторичному индексу.
  • Атомарное обновление для группы документов (Или имитировать атомарное обновление через управление версиями на уровне таблицы).Очень важно, чтобы группа документов (из фильтра) рассматривалась конечным пользователем как обновленная вместе.
  • Должно быть легко поддерживать множество таблиц.Каждая таблица будет хранить категорию элементов, и каждая категория имеет отдельную схему.
  • Должно быть легко добавить составной индекс.Критерии фильтрации могут измениться в любое время (Запросы к фильтрам не определены заранее).Лучше было бы, если хранилище данных позволяет быстро фильтровать все возможные комбинации столбцов (по умолчанию поставляется со всеми возможными составными индексами).Фильтры могут быть равны запросам или ранжировать их.

Необязательно

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

Не требуется

  • Высокая доступность
  • Сильная согласованность (возможная согласованность работает)
  • Высокая пропускная способность записи или низкая задержка записи

Шаблоны запросов 

{
  "item_id": "1234",
  "brand": "adidas",
  "average_price": 123,
  "rate_of_sale": 123,
  "visual information": {
    "img_url": "http://imgsdsd",
    "color": "red"
  }
}
  • Получить все товары бренда Adidas по цене от 100 до 200 и отсортировать набор фильтров на основе rate_of_sales.
  • Обновите все элементы rate_of_sales на следующий день на основе csv.Это должно быть атомарное обновление или создание новой таблицы, копирование данных с новыми ro, удаление старой таблицы и указание приложением новой таблицы.

1 Ответ

0 голосов
/ 01 октября 2018

Поскольку требуется горизонтальная масштабируемость, транзакционное хранилище, такое как Mysql, не работает.

Поскольку вам нужны составные индексы, хранилища ключевых значений, таких как Redis, Aerospike, и расширенные значения ключей, такие как HBase, Cassandra, могут быть исключены.

Если у вас много составных индексов, MongodB неэффективен.

Упругий поиск или Solr поддерживает все варианты использования (кроме атомарного массового обновления), хотя это можно решить с помощью псевдонимов, если вы обновляетевесь индекс.

Solr, как правило, эффективен при многократном обновлении документа.

Вы также можете рассмотреть возможность использования Mysql и разделения на уровне приложения, если число составных индексов не много.

https://db -engines.com / ru / rating - хороший сайт для сравнения хранилищ данных.

...