Какую СУБД лучше выбрать?

Question

[jonasas]

Что есть:
Имею прайс лист бесконечной длины (нужен шардинг). В качестве первичного ключа используется unsigned int64, который является некоторой хеш-суммой всей записи (для уникальности). Он всегда известен заранее (перед вставкой/обновлением).
Что нужно с этим делать:
Очень много вставлять/обновлять, выбирать записи по ПК. Разбивать на шарды, реплицировать мастер-слейв. СУБД должна иметь клиентские либы для C/C++.

Когда проект начинался, над большими объёмами данных никто особо не задумывался, используется Mysql (innodb). Теперь система кряхтит под нагрузкой, надо менять архитектуру.
Я понимаю, что в данной ситуации нужно использовать NoSQL, и большинство будет мне рекомендовать MongoDB. С этой СУБД я немного работал. Но меня очень не порадовали скорости её работы. Возможно, я не умею её настраивать. Тогда дополнительный вопрос: где можно почитать о настройке?

И ещё буду очень благодарен, если примерно (хотя бы порядок) сориентируете меня по цифрам скорости вставки и выборки, которых можно достичь (VPS Xeon 4 Core, 64 GB DDR4 ECC, SSD RAID-1)

Сейчас вставка/обновление 5000 записей занимает от 5 до 30 секунд! Это очень долго!

Спасибо!

Answer 1

[Юрий Ярош]

Эмм... для начала нужно выучить мат часть и разобраться что такое B-tree и R-tree и как они фигурируют в современных СУБД, разобраться что такое "6ая нормальная форма" (второй курс универа).

Если это мускуль у которого "бесконечная длинна" таблички - от 200Гб и до 1Тб, то достаточно просто использовать ENGINE ARCHIVE c R-tree индексом. В противном случае (если меньше 200Гб) нужно (учить мат часть и вправлять мозги) рефакторить базу. Лучше слезть с MySQL на PostgreSQL, а вот c MongoDB - куча проблем. Стандартные СУБД на основе B-tree для баз от 200Гб+ не подходят. MySQL исключение из-за модульности системы хранения, имеется ввиду ENGINE ARCHIVE, но так как там нет T-tree - нужен нормальный кэш. PostgreSQL даже похуже будет - нужно ковырять различные расширения типа cstore_fdw и т.п.

uint64 ID'шник в виде хэша - очень спорное решение, даже если и предположить что в какой-то вселенной нет коллизий, то точно не в этой, и дополнительно нужно прогонять фильтр Блума. Хотя, лучше всего, просто использовать композитные ключи и не заморачиваться.

Можно ещё попробовать HBase в Apache Phoenix обернуть, там уже есть всё готовое - и фильтр Блума и индексация, можно даже X-tree оформить. HBase, кстати, хорошо масштабируется на запись, а Cassandra, наоборот, - на чтение.

Шардинг (партицирование) и репликацию нужно оформлять когда схема хорошо нормализирована, и когда более-менее ясно какие таблички нужно масштабировать на запись, а какие на чтение - где-то нужен CA, где-то CP, а где-то AP... (CAP теорема)

Очень весело в PostgeSQL писать сишные функции для агрегации в материализованные представления, особенно весело с GPGPU.

Comments

[sim3x]

>6ая нормальная форма

зачем шестая?

[jonasas]

Идентификатор в виде хеша нужен для связи с СУБД полнотекстового поиска. Коллизии пока не так страшны, хотя понимаю, что нужно думать наперёд. Встаёт вопрос: как фильтр Блума поможет избегать коллизий (по Вашему ответу это звучит так)?

Java -- хорошая штука, мой любимый язык, но он всё равно будет уступать в производительности полностью компилируемым программам. И, к тому же, на Java менее рационально используется память, нежели на C/C++ (хотя всё зависит большей частью от программиста, особенно на C).
Но HBase и Cassandra мне понравились, нужно будет попробовать.

Таблица (коллекция) всего одна. Таблица нормализована максимально, чтобы не иметь каких-то реляционных зависимостей. Очень важна скорость выборки, а JOIN-ы априори будут медленнее, чем их отсутствие.

[Юрий Ярош]

sim3x если у человека есть история возникновения каких либо событий - нужна 6ая

[Юрий Ярош]

jonasas тут что-то не так... Лучше конечно взять и руками написать полнотекстовый поиск на Solr под конкретную задачу, чем городить Sphinx/Elastic.

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

"java нерационально использует память" - тут всё зависит от прямоты рук и понимания подкопанной, "утечки" возможны и на Java. Бывает что нужно делать offheap кэширование, но это, скорее, исключение из правил. По поводу производительности сейчас ситуация не очень однозначна: Hotspot довольно продвинутая штука - большой разницы между ним и llvm'ом, после прогрева нет.

"Таблица нормализована максимально, чтобы не иметь каких-то релятивных зависимостей" - как это связано с понятием нормализации ?

Если нужно денормализировать - можно спокойно использовать индексированное материализованное представление. В общем профилировать, профилировать и ещё раз профилировать... а не разбрасываться фразами "JOIN-ы априори будут медленнее, чем их отсутствие" - для того что бы этого не было, нужно разобраться с индексацией под конкретные запросы и кэшированием в рамках самого планировщика СУБД.

[sim3x]

Юрий Ярош: истории как раз не наблюдаю

[Юрий Ярош]

sim3x: а я не могу заванговать, но предполагаю что речь идёт о каком-то безразмерном логе...

[Юрий Ярош]

А вообще jonasas , стоит прочитать книжку https://pragprog.com/book/bksqla/sql-antipatterns
Что бы было понимание, что и куда...

Конкретно в случае с "вставкой 5000 записей" - нужно нормализировать и нормально индексировать, денормализация в таком случае приведёт к значительной потере производительности.

Потому что если есть табличка (u64, varchar(255), varchar(255)) то для её обновния и вставки нужно на много больше времени (в 20-50 раз) чем для (u64, u64, u64), ну и индексы тоже проставить нужно... а индексация varchar'а - дело просто идиотское.

[jonasas]

Реализовал задачу при помощи Cassandra+Redis. Со вставкой и чтением кассандра справляется на ура! + плюшки по стабильности, реплицированию, шардингу. Теперь надо сделать обработку MapReduce.

[Юрий Ярош]

jonasas: зависит от задач, для логирования с последующими DataMining'ами всётаки HBase гибче и шустрее.

[jonasas]

Юрий Ярош: Я же писал в описании вопроса, что храню прайс-листы. Т. е. сущность -- товар. Cassandra пока очень устраивает. Если появятся причины, по которым она будет не подходить, начну рассматривать другие варианты. А пока с точки зрения горизонтального масштабирования преград никаких нет.

[jonasas]

Начал работу с Hadoop. Адаптер ColumnFamilyInputFormat почему-то присылает много (10%) несуществующих данных. Ключ есть, а полей нет. И в БД не существует записей под этими ключами. Что это может быть?

[Юрий Ярош]

jonasas Быстрее всего, неправильно выбран формат результирующих файлов и/или неправильно построена задача - принимать данные оно будет, но естественно результаты будут в виде мусора для Cassandra. Вот пример задачи https://svn.apache.org/repos/asf/cassandra/trunk/e...

А вообще...
Hadoop сейчас довольно редко используется в серьёзных проектах из-за кучи оверхедов и проблем поддержки - нужно обязательно привязываться к какому-то вендору, у меня в проектах были почти все и мы остановились на IBM. Все остальные конторы, которые не идут подобным путём - просто не используют Hadoop стэк и Zookeaper в частности (Netflix, Spotify). В основном это поделки в стиле
Kafka -> Hbase -> Storm -> Spark -> (опционально) Storm -> Hbase -> Phoenix -> Hibernate + MVC что-то там.

А я сейчас уплыл, точнее убежал, в ScyllaDB.

[jonasas]

Юрий Ярош: Ничего не понял из первого абзаца ответа.
Когда разбирался с Hadoop, все эти примеры изучил.
У меня то вопрос -- откуда берутся несуществующие данные. Можно, конечно, выяснить это дебагом. Но это довольно долго, поэтому я интересуюсь, не сталкивался ли кто-нибудь с этой проблемой.

По поводу ScyllaDB. Она вышла совсем недавно и очень меня порадовала. Но она же должна быть ещё совсем сырой. Рано пока её использовать в продакшн.

Answer 2

[Дмитрий Авилов]

У вас есть уникальный айди сущности, у вас нет работы с записями (только получение/вставка по айди), что тут можно использовать кроме redis? Который спокойно обрабатывает сотни тысяч запросов в секунду?
try.redis.io - посмотрите и восхититесь.
redis.io/clients - клиенты тут, подо что хотите.
redis.io/documentation - много и интересно, как настраивать.

Comments

[jonasas]

С редиской много работал, но пока почему-то в голову не приходила мысль, что ей можно воспользоваться в этой ситуации. Спасибо, очень интересная идея!

[jonasas]

Хотя, тут встаёт вопрос. Redis держит все данные в ОЗУ, при этом синхронизирует с ПЗУ. Но данных то очень много, слишком расточительно их постоянно держать в ОЗУ. Может ли Redis держать только часть данных в ОЗУ (вроде кеша)?

[Дмитрий Авилов]

redis.io/topics/faq вот тут ваш вопрос освещается, в том числе. Но скажите, что вы там храните. что вам не хватит десятков гигабайт памяти... Если там основная масса - архивные данные, то убирайте их потихонечку, в redis есть прекрасный метод, который удаляет данные по таймеру. Значит ваша архитектура - запрашиваете объект в редисе, если его нет - запрашиваете в большой и медленной базе (как сейчас), если есть - возвращаете и продлеваете время жизни записи.. Когда вставляете/изменяете - сразу вставляете в редис, устанавливаете время удаления, потом не спеша вставляете в медленную базу. Будет летать на часто используемых записях и совсем чуть-чуть тормозить на редких.

[jonasas]

Дело в том, что архивных данных нет. Все записи могут быть запрошены примерно с одинаковой вероятностью. В mysql сейчас эта табличка весит 7Гб (правда, там пока есть индексы). Это 18млн записей. Тогда по идее, для 32гб озу мне получится хранить примерно 100млн записей. Неплохо)

[Дмитрий Авилов]

Тю, я-то думал... Настройте следилку, чтобы не проворонить момент, когда нужен будет апгрейд памяти на сервере и делайте простой редис, память нынче дешёвая.

[jonasas]

Но всё же, очень хотелось бы иметь пару индексов для выборки и сортировки. Тогда в редиске можно создать пару коллекций для этого?

[Дмитрий Авилов]

Конечно, нужно заранее все эти выборки и сортировки продумать. Например по дате обновления элементарно делается sorted set с ключом времени, с групировкой, например, по поставщику - тоже несложно... Немножко извратиться придётся, чтобы добавить в NoSQL функциональность реляционных баз, зато летать будет, а вам, как я понял, это важнее, чем неудобства при разработке.

[jonasas]

Пока мне эта идея очень нравится. Но вот были проблемы, когда я использовал редис на продакшене. Иногда мне прилетали ошибки типа "Redis has gone away". Тогда я не особо уделял этому внимание, так как это всего-лишь кэш. Я просто понизил TTL, проблемы ушли. Тогда БД занимала где-то 80ГБ, что больше, чем размер озу. Как быть со стабильностью?

[Дмитрий Авилов]

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

[Юрий Ярош]

Дмитрий Авилов если у человека БД будет больше 60Гб - Redis не вариант...
Да и выборка с LSM-tree на хэштаблице не очень то и производительна (привет fusion-tree, привет Ван Емде Боас).

[jonasas]

Полностью сделать всё на редис не получилось, так как он получается экономически не оправданным. ОЗУ сильно дороже ПЗУ.

Answer 3

[beduin01]

Попробуйте ArangoDB, я на нее с MySQL перешел. Пока очень доволен.

Answer 4

[Станислав Макаров]

Соглашусь с Дмитрий Авилов - если выборка по единственному ключу, то рел. СУБД ни к чему. Монга не единственное возможное решение, поэкспериментируйте с другими NoSQL базами.

Comments

[Юрий Ярош]

Станислав Макаров Mongo key-value ? Мдя...
Вообщем-то монга так же реляционна как и MySQL, c PostgreSQL'ем.
Потому что B-tree, потому то ссылки в Монге - это тоже что и FK любой SQL базы, потому что нормализация docs.mongodb.org/v3.0/core/data-model-design/#data...

[Станислав Макаров]

Юрий Ярош
> Mongo key-value ?
Я имел в виду NoSQL. Не люблю этот термин, он слишком общий и неточный, хотя конкретно тут подходит. Я изменю ответ.
> Вообщем-то монга так же реляционна как и MySQL
хм, ну Си тоже тогда объектно-ориентированный язык, почти такой же как C++, потому что в Си есть указатели на функции и ими можно запилить полиморфизм.
Вас не смущает хотя бы то, что первая нормальная форма требует работы с атрибутами как с атомарными значениями, в то время как Монга имеет first-class поддержку иерархических структур? Ссылки становятся лишь одним из вариантов связей между документами.
Ну и вообще, если бы Монга была реляционной БД настолько, насколько постгрес, ей бы стоило реализовать поддержку SQL. Делать реляционную базу без поддержки SQL на сегодняшний день - убить проект в самом начале.

[Юрий Ярош]

... на Сишке и дженерики макросами можно делать
Ok, в PostgreSQL и в Oracle тоже есть поддержка любых типов (иерархических и не только), проехали.
Эм... "реляционность" MongoDB это следствие использования B-tree в качестве индекса, но монга не ACID в общем понимании MVCC - нет полноценной атомарность и изоляции операций. по этому её часто называют "нереляционной", хотя на самом деле это не так... просто не более чем маркетинговая уловка и PR для привлечения инвестиций в далёком 2008ом.

Главным преимуществом монги в своё время являлась возможность вызова релятивных запросов и комманд с JS окружения, в том числе и с браузера - это позволило провести хорошую работу с сообществом (PR) и собрать толпу "верующих в масштабируемость /dev/null". Так что наличие SQL в монге угробило бы её как OpenSource продукт.

[Станислав Макаров]

Юрий Ярош
> в PostgreSQL и в Oracle тоже есть поддержка любых типов
работа с JSON или XML это как раз таки выходит за рамки возможностей традиционной реляционной БД. В стандарт SQL даже добавили новые функции для работы с тем же XML, не говоря уже о том, что напихали в свои СУБД различные вендоры. В конкретных СУБД могут быть и более экзотические типы данных, это нормально, т.к. производители удовлетворяют потребности клиентов. Тот же постгрес в свое время приобрел некоторые черты объектно-ориентированных баз за счет поддержки OID.
> Эм... "реляционность" MongoDB это следствие использования B-tree в качестве индекса
совершенно не понимаю как "реляционность" (пусть даже в кавычках) следует из использования B-дерева как и любого другого типа индекса. Используя индексы вы находите физическое расположение данных быстрее (значительно), чем делали бы это последовательным поиском, и не более. Это позволяет, имея значение индексированнного поля (например, id), вытащить всю остальную запись (документ, объект, etc). Как это делает базу реляционной?
> монга не ACID в общем понимании MVCC - нет полноценной атомарность и изоляции операций
да, пожалуй это так. Насчет инвестиций могу ошибаться, но кажется их привлекали, показывая систему с надежно работающей репликацией "из коробки" (разумеется за счет снижения гарантий ACID) и прочими вещами, более проблемными для РСУБД.
> Так что наличие SQL в монге угробило бы её как OpenSource продукт.
Я даже не ожидал, что вы попытаетесь объяснить это с точки зрения маркетинга. Я пытался вам показать, что он там совершенно не к месту, т.к. разрабатывался для реляционных систем.
Извините, я пока не понял почему монга - реляционная СУБД

Answer 5

[Пума Тайланд]

Вставляйте скопом а не по одной записи ну и если по одной то выключайте индексы а потом включайте

Comments

[jonasas]

Так я и вставляю банчами по 5000 записей. А альтер огромной таблицы выполняется очень долго и блокирует её для записи.

[sim3x]

jonasas: альтер? может апдейт?

[Юрий Ярош]

Пума Тайланд "ну и если по одной то выключайте индексы а потом включайте" спасибо, посмеялся от души...

[Пума Тайланд]

Юрий Ярош: ну так вставили миллиард и включили, а вы как это делаете ?

[Пума Тайланд]

jonasas: а какая у вас струкрута таблицы? и индекс только ваш хеш?

Answer 6

[napolskih]

Попробуйте tarantool. Это очень перспективная субд похожая на редис, но с очень широкими возможностями. Из минусов - не такая популярная и широкоиспользуемая.

Comments

[jonasas]

Посмотрел тарантул. Штука прикольная, но для продакшн надо её сильно допиливать -- писать разные обёртки для клиентов (официальные очень слабенькие) итд