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

Всем привет, настал такой вопрос, имеется проект на 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 сервер чтобы держать отдельно от серверов БД.
  • Вопрос задан
  • 497 просмотров
Решения вопроса 1
firedragon
@firedragon
Senior .NET developer
Кто вам сказал что NoSQL быстрее?
По факту можно расставить бд по быстродействию

keyvalue
sql
NoSQL

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

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

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

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

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

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


P.S. Не удивлюсь, если в итоге выяснится, что вся проблема сводится к истории, которая случилась в одном маленьком интернет-магазинчике: там тоже купили аж 3 сервера по 256Г мозгов в каждом, мастер-слейв, все дела... И не поменяли дефолтное значение innodb_buffer_pool_size в 128М. И что характерно, этот "кластер" даже тащил какое-то время, пока не случилась 10х нагрузка.
Ответ написан
batyrmastyr
@batyrmastyr
1) > чтобы хранить весь массив данных в виде json
JSON уже давно можно хранить в самом MySQL, если вам нужно произвольное число параметров, но значения их скалярные. Для индексации - виртуальные колонки и индексы по ним.
Если хочется найти искать «1» в массиве [1, 2,5], то вам в PostgreSQL.
2) «Полнотекстовый поиск» — что вы от него хотите? Если вам нужно точное совпадение, только быстрее, то берите что угодно.
Если вам нужен учёт словоформ, то он есть как минимум в Монге, Эластик, Постгрес, Сфинкс/Мантикора.
Если вы хотите больше контроля (поиск с учётом особенностей > 1 языка, тюнинг морфологии, какое-то ранжирование), то выкидываем Монгу (нет тюнинга морфологии и ранжирования, а на каждый язык нужно вешать отдельный индекс).
Если вы и ранжирование хотите тюнить (вплоть до простенького машинного обучения) и вообще максимальную скорость поиска, то вас спасёт только Мантикора/Сфинкс, всё остальные грустно глотают пыль.

Но золотая середина - Постгрес. На него довольно легко перекатиться и он избавляет от необходимости разводить NoSQL зоопарк.
P.S. И забудьте про монгу, Постгрес лучше неё почти по всем параметрам.
Ответ написан
Комментировать
Revencu
@Revencu
имел данные в таблицах MYSQL (основная имела 170 миллионов записей)
слил на еластик и на монго
еластик летел в поисках, а вот монго значительно уступал при чём надо создавать индексы для полей монго по которым текст поиск должен производиться. Для меня выбор - однозначно ElasticSearch
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы