Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / NoSQL, Big Data Новый топик    Ответить
 денормализация mysql OLTP на базе MongoDB  [new]
alexanoid1
Member

Откуда:
Сообщений: 59
Есть MySQL OLTP система со множеством отношений между таблицами. Например есть таблица products и вокруг нее десятки связанных таблиц.. различные типы, описания, скриншоты и так далее. Отношения между ними как 1 к 1 так и 1 ко многим, много ко многоим. Для отображения на клиенте каталога продукции необходимо делать запросы к mysql используя сложные joins что очень негативно сказывается на производительности.

Возникла идея денормализировать сущность product. Тоетсь при наступлении любого из CRUD событий с продуктом, мы будем формировать сообщение об этом в gearman queue а на другой стороне gearman worker будет создавать полное денормализированное представление продукта со всеми зависимостями и формировать документ на базе JSON и сохранять его в колекции products MongoDB.

С этим все более менее понятно, но вопрос возникает по след поводу - у продукта могут быть комментарии от пользователя. У каждого продукта их может быть разное число. Когда мы отображаем каталог продуктов возле каждого продукта хотелось бы показывать это число комментариев. Понятно что на лету просчитывать count для каждой записи в реляционной структуре это не самый лучший вариант. Здесь тоже напрашивается решение с отложенной обработкой через gearman queue который или будет заново пересчитывать через count общее число коментов для продукта и писать в mongodb либо делать +1 на числе из mongodb и обновлять там значение.

Вопрос - где лучше в Монго держать значение comments_number ? в той же коллекции products в отдельном филде или полностью в отдельной коллекции ?

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

Посоветуйте плиз как лучше организовать данные в Монго для описанных мной сценариев. Спасибо !
9 сен 14, 12:40    [16553802]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
alexanoid1,

А зачем в этой схеме Монго? Кто мешает денормализованные данные хранить в том же MySQL?
В блобах в json. Вытащив наружу поля, по которым хотите сортировать или фильтровать?

Если у вас новые комментарии появляются не по 100 в секунду, то их можно и в реляционке оставить и даже просчитывать при чтении автоматически, способов куча )
9 сен 14, 13:57    [16554299]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
alexanoid1
Member

Откуда:
Сообщений: 59
просто хочу сразу убежать от модели вертикального масштабирования на горизонтальное(именно для клиентских запросов которых могут быть сотни тысяч и миллионы). Плюс для денормализации NoSQL изначально и был изобретен и оформлен в отдельную концепцию которую обычно приходится изобретать самому на базе RDBMS. С ростом трафика к NoSQL будем просто подкидывать новые узлы и тем самым не думать о распределении нагрузки.

Вопрос только где держать поля которые намного чаще будут изменяться чем теже поля содержащие в себе документы продуктов.
Держать эти поля(comments_number, downloads_number) вместе с product в одной колекции products или разнести их по разным колекциям ?
9 сен 14, 14:23    [16554455]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
scf
Member

Откуда:
Сообщений: 1486
alexanoid1,

Я так понимаю, что монга будет использоваться фактически в качестве кеша, в который асинхронно будут перегонятся изменения из основной базы и основной профиль - "мало записи, много чтения".

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

НО - я думаю, что ваши вопросы заданы в неправильном порядке. Важнее, тут, наверное, именно сортировка, поиск и пагинация, а извлечение продуктов вторично. Посмотрите на SOLR или Sphinx - он решит все ваши проблемы, параллельно добавив полнотекстовый поиск с автокомплитом, извлечение фасетов и многое другое.
9 сен 14, 22:38    [16556864]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
alexanoid1
Member

Откуда:
Сообщений: 59
scf, спасибо за ответ.

Да, sphinx уже установлен в системе и рассматривается как система полноценного поиска. На счет фильтрации, сортировки, пейджинации удивлен что он(sphinx) может помочь, но это скорее от моего незнания возможностей этого продукта. Займусь его изучением.

Несколько смутило ваше замечание по поводу извлечение продуктов вторично
А если оно не вторично а так же важно как и критерии описанные выше то как здесь быть ? Решит ли sphinx и эту проблему ?
9 сен 14, 23:55    [16557029]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
scf
Member

Откуда:
Сообщений: 1486
alexanoid1,

со Sphinx плотно не работал, но в Solr есть и возможность вместе с индексом хранить дополнительные поля (в вашем случае - json с продуктом), и пагинация, и фильтры по полям, и, разумеется, сортировка.
10 сен 14, 02:31    [16557232]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28165
scf
коллекция "продукты", с индексами на поля, по которым сортировать и фильтровать надо. Кол-во комментом имеет смысл хранить там же...
+1
10 сен 14, 09:45    [16557627]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
alexanoid1
просто хочу сразу убежать от модели вертикального масштабирования на горизонтальное(именно для клиентских запросов которых могут быть сотни тысяч и миллионы).

Ну, тот же MySQL в основном и используют в системах для горизонтального масштабированияю. Благо решений для этого куча.
А что, у вас планируется миллионы запросов в секунду? Или это про запросы в сутки - но тогда там и одного сервера хватит с избытком.

alexanoid1
Плюс для денормализации NoSQL изначально и был изобретен и оформлен в отдельную концепцию которую обычно приходится изобретать самому на базе RDBMS.

Это, мягко говоря, не верное утверждение.

alexanoid1
С ростом трафика к NoSQL будем просто подкидывать новые узлы и тем самым не думать о распределении нагрузки.

Я вот еще не видел реальных внедрений, где бы все так просто было.
Ну и обычно получается, что для того, что бы держать какие-нибудь очевидные миллионы запросов в сутки городят облако из 10 машин, хотя и одной хватило бы. Увы, в Монго приходится платить минимум утроением числа машин по сравнению с MySQL.

Но вообще если нужен кэш (а вам нужен именно кэш, как основное хранилище Mongo, мягко говоря, не слишком пригоден), то лучше брать Redis или memcached. Оно и проще и быстрее.
12 сен 14, 14:20    [16568494]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
Dogen
Member

Откуда: Гондурас
Сообщений: 2974
Вообще не вижу причин не обходиться одним MySQL.

Все эти "непонятное число комментариев" в прилично нормализованной структуре быстро вытаскиваются. Количество комментариев можно увеличивать при записи комментария, ну, раз в месяц проверять целостность базы...

Все разговоры о негативном сказывании без цифр бессмысленны. Оно кем-либо замечается, это сказывание? Не думаю ведь.

А сколько товаров-то?
12 сен 14, 16:09    [16569302]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
Dogen
Member

Откуда: Гондурас
Сообщений: 2974
alexanoid1
Для отображения на клиенте каталога продукции необходимо делать запросы к mysql используя сложные joins что очень негативно сказывается на производительности.

Прямо так ко всем NN таблицам сразу? Для вывода каталога? Или все-таки карточки товара?
12 сен 14, 16:10    [16569312]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
alex564657498765453
Member

Откуда:
Сообщений: 1925
поддерживаю тех, кто щитает, что прежде чем думать о построении звездолёта, обгоняю
щего аналогинчые системы гугла или амазона, нужно подумать - а будет ли такая нагрузка.

лично я не увидел причин для монго...

ну надо денормализованое хранить - чем мускл не подходит(или отдельная копия мускла на отдельном сервере раз переживаете за производительность).

монго хороша когда нет чёткой структуры... пока структура чёткая...я бы не парился...

ЗЫ
на конференциях бигдата, часто слышно - ноускл хорошо, вот для той задачи той конторы где родилась та или иная ноускл субд... а вот другим...

ЗЫЗЫ
мне советовали(ещо не пробовал) когда речь идёт о том что нам надо мускл и чучуть монго, посмотреть на постгри, где в новой версии есть возможность хранить json значения.
16 сен 14, 15:02    [16581393]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: денормализация mysql OLTP на базе MongoDB  [new]
Евгений_111sd
Member

Откуда:
Сообщений: 1
как провести денормализацию такой структуры?

К сообщению приложен файл. Размер - 57Kb
9 июн 16, 16:11    [19277014]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3626
с какой целью, студент?
14 июн 16, 09:41    [19289998]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
alexanoid1,

как бы денормализация для решения проблем производительности join ов - это как бы позапрошлый век...

join - быстрая операция, её не нужно пытаться убирать, и современные тенденции решения проблем хранилищ - это, наоборот, супернормализация.
29 июл 16, 08:20    [19470723]     Ответить | Цитировать Сообщить модератору
 Re: денормализация mysql OLTP на базе MongoDB  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
scf
alexanoid1,

со Sphinx плотно не работал, но в Solr есть и возможность вместе с индексом хранить дополнительные поля (в вашем случае - json с продуктом), и пагинация, и фильтры по полям, и, разумеется, сортировка.



вот именно, нахрена ему тогда вообще моего?

внешний индекс на Solr или elastic search - и Всё....
29 июл 16, 08:31    [19470744]     Ответить | Цитировать Сообщить модератору
Все форумы / NoSQL, Big Data Ответить