Какой стэк использовать для быстрого доступа данных?

Question

[mr.bob]

Всем привет, настал такой вопрос, имеется проект на PHP (самописный CMS) + Mysql (сервер nginx + php-fpm + memcached) все супер, но, нарастает нагрузка на БД, т.е. запись и чтение. Вот теперь подумываю над тем чтобы использовать NoSQL для прослойки между перед Mysql чтобы было легче для отбора и поиска, т.к. одна запись имеет множество свойств (грубо говоря) и они раскидываются примерно по 8 таблицам. Бывает на 1 запись бывает по несколько записей в одной таблице. И вот, сейчас как то с нагрузками все ок но думаю надо подумывать об масштабировании и оптимизации, чтобы хранить весь массив данных в виде json в noSql и далее записывать отложенно в сам mysql и также при чтении, чтобы брать из nosql системы. Можете подсказать какую использовать систему? Посматриваю ElasticSearch (далее ES), redis, mongodb.
Честно напишу, работал только с ES, удобная вещь, но, при запросе с пагинацией используется scroll с временем и что неудобно. С redis был опыт только очереди сообщении и все. А вот mongoDB никак не трогал.
В БД порядка 300 тыс основных записей, остальные записи связанных таблиц примерно также +- 30% и база будет нарастать. Можете посоветовать какую использовать nosql и будет ли профит ее использования при увеличении БД? Уже кластеризацию сделал, есть 2 сервера (1 мастер и 1 слейв), для nosql думаю использовать пока 1 сервер чтобы держать отдельно от серверов БД.

Comments

[mayton2019]

Mongo предполагает что система у вас тяготеет не к таблицам а к документам. Причем поиск может быть по любому полю. Вот как-то так. Разумеется joins никто там не делает. Тоесть данные у вас изначально должны быть как-то денормализованы и разложены в агрегаты.

Elastic - это просто поисковая система над unstructured или semi-structured информацией. Всеядная система. Можно ей логи скормить например.

[alexalexes]

А какие мероприятия по оптимизации вы проводили?
Анализировали план выполнения запросов?
Оптимально ли составлены сами тексты запросов (или все скрыто под покровами ORM)?
Все ли индексы отвечают потребностям выборки данных?
А не забыли ли про связи между таблицами, или они только на уровне софта подразумеваются?
Нет ли очередей мелких запросов там, где можно сделать один запрос, но на всю выборку?
300 тыс записей - это детский размер для реляционной базы.

[mr.bob]

alexalexes, оптимизацию провел. Лишние связи, столбцы и таблицы что объединить мог все сделал. Индексы созданы и соответствуют потребностям. Связи между таблицами есть по ключу, на добавление/редактирование/удаление. Очередей нету, все стараюсь в кэш пихать с метками обновления. Да понимаю что 300 тыс не много, но, уже сейчас хочу попарится с оптимизацией и с учётом роста данных и запросов

[mr.bob]

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

[mayton2019]

mr.bob, не совсем понял что там было неудобно ну да ладно. Смотрите. Основной юзкейс Эластика - это к примеру система формирует тера-байты логов. И вам (случилась авария) надо срочно и быстро поискать по логам через эластик два-три ключевых слова. Вот здесь Эластик силен. Все остальные попытки его к чему-то прикрутить (к бизнес-логике) будут скорее всего провальны. Гарантии будут во много раз слабее чем при работе с монгой или с реляционной БД тем более.

[Ипатьев]

mayton2019, а для полнотекстового/фасетного поиска эластик совсем-совсем не подходит?

[Ипатьев]

mr.bob, что такое "10 тыс по пагинации"? 10 тысяч страниц? 10 тысяч результатов? сколько из них человек физически сможет просмотреть?

[mayton2019]

Ипатьев, скажу честно что насчет фасетного я не знаю. Мы использовали в основном для логов.

[Ипатьев]

mayton2019, у меня для вас большой сюрприз

[mayton2019]

Ипатьев, давайте его сюда.

[German Zvonchuk]

mr.bob посмотрите при помощи Blackfire что происходит у вас с запросами.
Сколько памяти, сколько процессорного времени, каким образом диск задействуется.
Я уверен что вы увидите узкие места, которые можно серьезно оптимизировать.

После этого, можно сильно снизить нагрузку на чтение БД путем кеширования данных.
Просто создавайте кеш в APCU или Redis или еще где... храните там готовые к употреблению данные.

Только тут надо подумать над инвалидацией кеша...

Answer 1

[Владимир Коротенко]

Кто вам сказал что NoSQL быстрее?
По факту можно расставить бд по быстродействию

keyvalue
sql
NoSQL

Причем что забавно под капотом используются keyvalue 30 летней давности. Это как болтовая винтовка, если вы понимаете.
Полнотекстовой поиск это отдельный вопрос, подразумевающий огромное место для хранения.
NoSQL же в своих индексах использует все то же самое, только не имеет информации о типах или придумывает

Comments

[mr.bob]

т.е. предлагает оставить также на mysql?
а elastic для поиска?

[Владимир Коротенко]

mr.bob,
Я вам предлагаю создать стенд.
Потом так же бессмысленно и беспощадно разбомбить его как Дрезден.
Снять характеристики и делать выводы.

Answer 2

[Vitsliputsli]

Оптимизация это всегда жертва чем-то, ради чего-то. Нельзя просто оптимизировать, нужно выбрать, что улучшать, а затем выбираеть решения, понимая, чем можно пожертвовать. Поэтому начинать оптимизацию нужно тогда, когда знаешь какую проблему решаешь.
Нельзя просто поставить прослойку перед MySQL и все станет хорошо, MySQL итак, очень быстрая СУБД. Но можно поставить, например кеширующий Redis, при условии, что у вас очень много key-value значений и крайне важен быстрый доступ к ним. Это решение не только увеличит занимаемое место и усложнит архитектуру, нужно будет контролировать консистентность баз данных, которая может быть нарушена из-за проблемы инвалидации кеша.
Оптимизация классических СУБД всегда начинается с построения наиболее подходящих индексов. Если этого уже не хватает и скорость чтения недостаточна, то можно ввести репликацию slave и читать из нее. Здесь опять возникнет вопрос дополнительных затрат на место и консистентности, особенно неконсистентности данных из-за лага репликации. Плюс затраты на дополнительное подключение, что впрочем можно решить внедрением proxy.
Далее более сложные варианты, от отказа от foreign keys, до шардирования. Но все это при действительно высоких нагрузках, заниматься этим на данном этапе не стоит, разве что, если есть предпосылки, что к этому придете, то заранее выбрать параметр шардирования (иногда это просто, а бывает очень сложно).

Answer 3

[Ипатьев]

Для "доступа" использовать ту реляционную БД, которая имеется в наличии. При появлении проблем с производительностью - диагностировать их, и с конкретными вопросами приходить на Хабр.
Для поиска - "быстрого", "по параметрам", полнотекстового - использовать предназначенный для этого движок, например Эластик. При появлении проблем с производительностью - диагностировать их, и с конкретными вопросами приходить на Хабр.

spoiler

Сам по себе ход мысли в вопросе очень характерный.
Звучит примерно так: "Купил машину, что-то плохо тянуть стала. Думаю докупить упряжку лошадей, чтобы запрягать спереди. Лошадиные силы ведь прибавятся! Посматриваю ещё на воздушных змеев, лыжи, и дополнительный омыватель". То есть вместо простых и очевидных действий по диагностике, формулированию конкретных проблем, и последующему ремонту машины мы фантазируем себе набор каких-то бессмысленных и хаотичных телодвижений. Которые мало того что вообще никак не помогут, но скорее всего ухудшат ситуацию.

И, разумеется, не приводим ни одной цифры, ни одного конкретного примера. Ни даже примерной нагрузки на систему - хоть в попугаях/посетителях. Ни загрузки процессора на серверах. Ни причин, по которым пришлось делать мастер-слейв. Ни текущей статистики по Mysql. Одни оценочные суждения, " А здоровье мое не очень. То лапы ломит, то хвост отваливается." Общие причитания про повышение нагрузки, "на запись и чтение". При том что запись уже больше не упоминается нигде, и непонятно - есть какие-то проблемы с ней, или нет. Да и с MySQL в целом.

В итоге из всех невнятных жалоб становится понятно, что с самой БД, судя по всему, проблем нет. А есть только один участок, к которому есть вопросы - поиск. Есть идея реализовать его через Эластик, но есть сомнения. При том что Озон там, МВидео и прочих мастодонтов Эластик устраивает, а вот нашему магазинчику с 300К записей он не угодил. Сразу вспоминается анекдот про нового русского и 600-й мерс с засорившейся пепельницей. Не тянет Эластик? Будем менять на Монгу!

Я думаю, что в таких ситуациях в первую очередь надо установить в систему здравый смысл. Перестать метаться с безумными фантазиями, а подойти к вопросу логически: есть вопросы к поиску? Значит надо поставить поисковый движок. поисковый движок - это в 99% случаев - Эластик. К нему есть вопросы? Отлично. Максимально подробно формулируем эти вопросы - не забывая привести индексы, конфиги, запросы - и задаём конкретный вопрос по оптимизации работы Эластика.

А сейчас проблема "может мне монгу воткнуть?" проходит исключительно по разряду "Когда коту делать нечего, он гигиеной занимается".

P.S. Не удивлюсь, если в итоге выяснится, что вся проблема сводится к истории, которая случилась в одном маленьком интернет-магазинчике: там тоже купили аж 3 сервера по 256Г мозгов в каждом, мастер-слейв, все дела... И не поменяли дефолтное значение innodb_buffer_pool_size в 128М. И что характерно, этот "кластер" даже тащил какое-то время, пока не случилась 10х нагрузка.

Comments

[mr.bob]

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

А пуканить и писать что такие дефолтные конфы как innodb_buffer_pool_size не меняли и так далее думаю стоит опустить.
Слава богу умеем пользоваться mysql tuner и читать логи и статистику.

И проект не "простой интернет-магазинчик" а своего рода сервис, к магазину и помине не имеет отношения.

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

[Ипатьев]

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

Answer 4

[batyrmastyr]

1) > чтобы хранить весь массив данных в виде json
JSON уже давно можно хранить в самом MySQL, если вам нужно произвольное число параметров, но значения их скалярные. Для индексации - виртуальные колонки и индексы по ним.
Если хочется найти искать «1» в массиве [1, 2,5], то вам в PostgreSQL.
2) «Полнотекстовый поиск» — что вы от него хотите? Если вам нужно точное совпадение, только быстрее, то берите что угодно.
Если вам нужен учёт словоформ, то он есть как минимум в Монге, Эластик, Постгрес, Сфинкс/Мантикора.
Если вы хотите больше контроля (поиск с учётом особенностей > 1 языка, тюнинг морфологии, какое-то ранжирование), то выкидываем Монгу (нет тюнинга морфологии и ранжирования, а на каждый язык нужно вешать отдельный индекс).
Если вы и ранжирование хотите тюнить (вплоть до простенького машинного обучения) и вообще максимальную скорость поиска, то вас спасёт только Мантикора/Сфинкс, всё остальные грустно глотают пыль.

Но золотая середина - Постгрес. На него довольно легко перекатиться и он избавляет от необходимости разводить NoSQL зоопарк.
P.S. И забудьте про монгу, Постгрес лучше неё почти по всем параметрам.

Answer 5

[Emil Revencu]

имел данные в таблицах MYSQL (основная имела 170 миллионов записей)
слил на еластик и на монго
еластик летел в поисках, а вот монго значительно уступал при чём надо создавать индексы для полей монго по которым текст поиск должен производиться. Для меня выбор - однозначно ElasticSearch