LINUX.ORG.RU

Выбор NoSQL

 ,


0

1

Посоветуйте выбрать DB для хранения логов (действия пользователя в системе). Искать нужно будет по ID пользователя (UINT32), времени (UINT64) - в качестве данных будут BLOB (cереализированные кастомные объекты) от пары байт до пары килобайт. Это все нужно быстро инсертить, и быстро искать (User ID + time period) - основное ПО написано на С++.

В принципе пока траффик не сильно большой (вполне справится какойто SQL сервер вроде MySQL/PSQL/Oracle) - но всеже хочется за недорого получить запас на будущее + маштабирование.

Вот присматриваюсь к cassandra - вродебы всем неплохо (тут и маштабирование и отказоустойчивость из коробки + есть куча док и всяких тулзов), но может есть какие подводные камни или решение полутчше ?

★★★★

Юзай «MySQL/PSQL» и не парься. Пока nosql-щики наконец определятся, что юзать в той или иной задаче, оно уже успеет выйти из моды, и процесс пойдёт сначала.

Если прям сильно трясутся коленки от желания заюзать «хоть какой-нибудь nosql» - посмотри на монгу.

anonymous
()

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

aedeph_ ★★
()
Ответ на: комментарий от aedeph_

nosql не столько о маштабировании и отказоустойчивости

Я б даже сказал, о чём угодно, но не об отказоустойчивости

nanonymous
()

Если у вас bulk select по хорошо определенным первичным ключам, в том числе, распределенным, то тогда cassandra в явных лидерах индустрии. Ей нет равных.

Но там нет join, нет вложенных select, от вторичных индексов толку мало, удаление очень дорогое, нет транзакций, целостность данных только eventual и еще чего-то такое, о чем забыл написать.

Подозреваю, что в mongo почти та же картина. В riak - тоже...

dave ★★★★★
()

PostgreSQL отлично умеет в NoSQL

anonymous
()

Посмотри что-то наподобие couchdb (к нему были замечания, но в плане вставки через curl картинок, JSON-ов, выглядит довольно удобным)

Не забывай, что и действующим пользователям должно быть еще удобно, например режим DNT и т.п. ;)

anonymous
()

В кассандре небось ключ для шардинга будет user_id, а сортированый ключ - timestamp. Учти что все данные для user_id должны влезать в одну машину. Распределенность работает только по несортированому префиксу первичного ключа. Эта часть первичного ключа в CQL идет в row key внутреннего представления в виде column family. То что сортруется - column name. Весь row должен влезать в одну машину

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

ClickHouse от Yandex

https://clickhouse.yandex/reference_ru.html

Это круче Postgres / MySQL для данной задачи. Вставляет данные пачками очень быстро. Хранит пожатое. Заточено под поиск по датам. Колоночное — легко добавить новую колонку, легко селектить диапазон какой-то колонки по дате. Умеет работать на огромных кластерах (в яндексе: «374 серверов, хранящий более 8 триллионов строк (более 1 квадриллиона значений) в базе данных. Объём сжатых данных, без учёта дублирования и репликации, составляет около 800 ТБ. Объём несжатых данных (в формате tsv) составил бы, приблизительно, 7 ПБ.»)

CASSANDRA vs CLICKHOUSE

«В Cassandra больше упор на полуструктурированные данные, по аналогии с BigTable. Можно иметь совершенно разный набор столбцов для разных ключей; количество столбцов может быть неограниченным. Но такой способ хранения данных менее оптимальный для их сканирования. Грубо говоря, на каждый ключ, во время чтения, приходится разбираться с тем, какие столбцы для него есть. Для сравнения, в ClickHouse структура таблицы жёсткая, хотя столбцов может быть достаточно много, и значения в них могут быть сильно разреженными.»

«Cassandra больше ориентирована на key-value сценарий работы: чтение и обновление данных по ключу. Но в аналитических базах данных, чтение по ключу с низкой latency не требуется, и за счёт этого становятся допустимы такие оптимизации, как блочное сжатие данных более крупными блоками и разреженный индекс. В аналитических базах данных, одной строчке уделяется мало внимания, вся обработка данных рассчитана на обработку целыми пачками. Чтобы уметь обновлять данные по ключу, требуется на каждую строчку иметь некоторые дополнительные данные — например, номер версии и timestamp. В Cassandra используется LSM-Tree, значит при обновлении, в базу пишутся записи вида «что и как обновить». Эти записи надо мерджить при чтении и это довольно дорого, если требуется выполнять не точечные чтения, а обработку пачек данных. В аналитических базах данных, для эффективного обновления данных, требуются сложные оптимизации.»

«Cassandra — key-value хранилище «на стероидах». Она конкурирует с HBase, Aerospike и подобными. Вы можете очень быстро записывать туда данные. Можете очень быстро получить любую запись по ключу. Но вы не можете сделать count(id) на петабайтовом кластере за секунду. Разумеется и у Cassandra, и у остальных конкурентов есть возможности делать аналитические запросы через MapReduce, однако из-за неколоночной структуры хранения данных такие запросы отнимают все равно слишком много времени и ресурсов. »

https://habrahabr.ru/company/yandex/blog/303282/

hlamotron
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.