Что есть:
Имею прайс лист бесконечной длины (нужен шардинг). В качестве первичного ключа используется unsigned int64, который является некоторой хеш-суммой всей записи (для уникальности). Он всегда известен заранее (перед вставкой/обновлением).
Что нужно с этим делать:
Очень много вставлять/обновлять, выбирать записи по ПК. Разбивать на шарды, реплицировать мастер-слейв. СУБД должна иметь клиентские либы для C/C++.
Когда проект начинался, над большими объёмами данных никто особо не задумывался, используется Mysql (innodb). Теперь система кряхтит под нагрузкой, надо менять архитектуру.
Я понимаю, что в данной ситуации нужно использовать NoSQL, и большинство будет мне рекомендовать MongoDB. С этой СУБД я немного работал. Но меня очень не порадовали скорости её работы. Возможно, я не умею её настраивать. Тогда дополнительный вопрос: где можно почитать о настройке?
И ещё буду очень благодарен, если примерно (хотя бы порядок) сориентируете меня по цифрам скорости вставки и выборки, которых можно достичь (VPS Xeon 4 Core, 64 GB DDR4 ECC, SSD RAID-1)
Сейчас вставка/обновление 5000 записей занимает от 5 до 30 секунд! Это очень долго!
У вас есть уникальный айди сущности, у вас нет работы с записями (только получение/вставка по айди), что тут можно использовать кроме redis? Который спокойно обрабатывает сотни тысяч запросов в секунду? try.redis.io - посмотрите и восхититесь. redis.io/clients - клиенты тут, подо что хотите. redis.io/documentation - много и интересно, как настраивать.
Хотя, тут встаёт вопрос. Redis держит все данные в ОЗУ, при этом синхронизирует с ПЗУ. Но данных то очень много, слишком расточительно их постоянно держать в ОЗУ. Может ли Redis держать только часть данных в ОЗУ (вроде кеша)?
redis.io/topics/faq вот тут ваш вопрос освещается, в том числе. Но скажите, что вы там храните. что вам не хватит десятков гигабайт памяти... Если там основная масса - архивные данные, то убирайте их потихонечку, в redis есть прекрасный метод, который удаляет данные по таймеру. Значит ваша архитектура - запрашиваете объект в редисе, если его нет - запрашиваете в большой и медленной базе (как сейчас), если есть - возвращаете и продлеваете время жизни записи.. Когда вставляете/изменяете - сразу вставляете в редис, устанавливаете время удаления, потом не спеша вставляете в медленную базу. Будет летать на часто используемых записях и совсем чуть-чуть тормозить на редких.
Дело в том, что архивных данных нет. Все записи могут быть запрошены примерно с одинаковой вероятностью. В mysql сейчас эта табличка весит 7Гб (правда, там пока есть индексы). Это 18млн записей. Тогда по идее, для 32гб озу мне получится хранить примерно 100млн записей. Неплохо)
Тю, я-то думал... Настройте следилку, чтобы не проворонить момент, когда нужен будет апгрейд памяти на сервере и делайте простой редис, память нынче дешёвая.
Конечно, нужно заранее все эти выборки и сортировки продумать. Например по дате обновления элементарно делается sorted set с ключом времени, с групировкой, например, по поставщику - тоже несложно... Немножко извратиться придётся, чтобы добавить в NoSQL функциональность реляционных баз, зато летать будет, а вам, как я понял, это важнее, чем неудобства при разработке.
Пока мне эта идея очень нравится. Но вот были проблемы, когда я использовал редис на продакшене. Иногда мне прилетали ошибки типа "Redis has gone away". Тогда я не особо уделял этому внимание, так как это всего-лишь кэш. Я просто понизил TTL, проблемы ушли. Тогда БД занимала где-то 80ГБ, что больше, чем размер озу. Как быть со стабильностью?
Не создавать базы большие, чем объём оперативки. Там всё отлично со стабильностью, если вы принимаете правила игры, то есть держите достаточно свободной памяти.
Вы почитайте сайт, там очень всё по делу и интересно, и все вопросы на которые я хотел узнать ответ там были. Ваши, наверное, тоже будут.
Соглашусь с Дмитрий Авилов - если выборка по единственному ключу, то рел. СУБД ни к чему. Монга не единственное возможное решение, поэкспериментируйте с другими NoSQL базами.
«Пользователь удалён»
> Mongo key-value ?
Я имел в виду NoSQL. Не люблю этот термин, он слишком общий и неточный, хотя конкретно тут подходит. Я изменю ответ.
> Вообщем-то монга так же реляционна как и MySQL
хм, ну Си тоже тогда объектно-ориентированный язык, почти такой же как C++, потому что в Си есть указатели на функции и ими можно запилить полиморфизм.
Вас не смущает хотя бы то, что первая нормальная форма требует работы с атрибутами как с атомарными значениями, в то время как Монга имеет first-class поддержку иерархических структур? Ссылки становятся лишь одним из вариантов связей между документами.
Ну и вообще, если бы Монга была реляционной БД настолько, насколько постгрес, ей бы стоило реализовать поддержку SQL. Делать реляционную базу без поддержки SQL на сегодняшний день - убить проект в самом начале.
«Пользователь удалён»
> в PostgreSQL и в Oracle тоже есть поддержка любых типов
работа с JSON или XML это как раз таки выходит за рамки возможностей традиционной реляционной БД. В стандарт SQL даже добавили новые функции для работы с тем же XML, не говоря уже о том, что напихали в свои СУБД различные вендоры. В конкретных СУБД могут быть и более экзотические типы данных, это нормально, т.к. производители удовлетворяют потребности клиентов. Тот же постгрес в свое время приобрел некоторые черты объектно-ориентированных баз за счет поддержки OID.
> Эм... "реляционность" MongoDB это следствие использования B-tree в качестве индекса
совершенно не понимаю как "реляционность" (пусть даже в кавычках) следует из использования B-дерева как и любого другого типа индекса. Используя индексы вы находите физическое расположение данных быстрее (значительно), чем делали бы это последовательным поиском, и не более. Это позволяет, имея значение индексированнного поля (например, id), вытащить всю остальную запись (документ, объект, etc). Как это делает базу реляционной?
> монга не ACID в общем понимании MVCC - нет полноценной атомарность и изоляции операций
да, пожалуй это так. Насчет инвестиций могу ошибаться, но кажется их привлекали, показывая систему с надежно работающей репликацией "из коробки" (разумеется за счет снижения гарантий ACID) и прочими вещами, более проблемными для РСУБД.
> Так что наличие SQL в монге угробило бы её как OpenSource продукт.
Я даже не ожидал, что вы попытаетесь объяснить это с точки зрения маркетинга. Я пытался вам показать, что он там совершенно не к месту, т.к. разрабатывался для реляционных систем.
Извините, я пока не понял почему монга - реляционная СУБД
Попробуйте tarantool. Это очень перспективная субд похожая на редис, но с очень широкими возможностями. Из минусов - не такая популярная и широкоиспользуемая.
Посмотрел тарантул. Штука прикольная, но для продакшн надо её сильно допиливать -- писать разные обёртки для клиентов (официальные очень слабенькие) итд
Простой
Простой
Средний
Сложный
Средний
