Комментарии 34
Кстати, первая картинка кликабельна :)
Загипнотизировал первой картинкой :)
А почему не выбрали NoSQL хранилище заточеное под хранение key-value?
Присоединяюсь к вопросу. Или что помешало использовать два хранилища — SQL и NoSQL?
По видимому из-за индексов:
Отсюда и появилась дополнительная компонента в виде быстрого демона, которую не получилось заменить системой memcached, т.к. нам нужно было использовать специфические индексы данных.
А потому что еще никто и не мешает потом сделать mysql connect и поиграть как угодно с данными повыбирать че нравится, поискать like по любым значениям.
Из любого NoSql тоже можно сделать любые выборки, перебрав все имеющиеся ключи(при вашем like ведь произойдет то же самое). А скорость работы в режиме key/value(те в основном режиме) будет выше на порядок. Конечно это не так удобно, но за то в бою работает быстрее.
Но самое главное — непонятно, зачем вам одна база данных с настройками, когда эти настройки легко раскладываются по шардам юзеров. Из статьи не очень понятно, для чего конкретно нужна единая таблица.
Но самое главное — непонятно, зачем вам одна база данных с настройками, когда эти настройки легко раскладываются по шардам юзеров. Из статьи не очень понятно, для чего конкретно нужна единая таблица.
При чем тут перебор ключей? Почему нельзя их в handler socket сделать? Да и mysql умеет это делать. Перебор это не бенефит nosql это способ работать с данными. Далее я както не понял а как вы все ключи то переберете? Гдето списочек будете хранить а вот в mysql range scan по первичному ключу будет всегда хранить не надо список.
Если говорить о nosql вы какой именно имеете в виду? В реальных условиях все что мы тестировали в случае когда данные перестают помещаться в память превращаются в ходячий и тормозной мусор умирающий на синхронной записи на диск. Это редис, это мемкешдб. А вот mysql в этих же условиях работает в 10ки если не в сотни раз быстрее. В частности со 120 серверов в 40 потоков с каждого через hadnler socket на чтение получил 600.000 запросов в секунду. Дальше просто шел упор в сетевушку, это при том что разумеется конекты были keep alive. без этого изза особенностей tcp ip выжать не смог более 70К запросов в секунду. После чего сделал 120К открытых конектов через которые прогнал теже самые 600.000 запросов в секунду с одного сервера.
Если говорить о nosql вы какой именно имеете в виду? В реальных условиях все что мы тестировали в случае когда данные перестают помещаться в память превращаются в ходячий и тормозной мусор умирающий на синхронной записи на диск. Это редис, это мемкешдб. А вот mysql в этих же условиях работает в 10ки если не в сотни раз быстрее. В частности со 120 серверов в 40 потоков с каждого через hadnler socket на чтение получил 600.000 запросов в секунду. Дальше просто шел упор в сетевушку, это при том что разумеется конекты были keep alive. без этого изза особенностей tcp ip выжать не смог более 70К запросов в секунду. После чего сделал 120К открытых конектов через которые прогнал теже самые 600.000 запросов в секунду с одного сервера.
Про перебор ключей — это я имел в виду эмуляцию селекта с like на nosql про который вы упомянули.
например kyoto cabinet умеет искать по префиксам ключей — так можно вынуть весь список нобходимых ключей.
Да noSql начинает тормозить когда упирается в диск. но использование hs никак от этого не уберегает: он так же встанет на большом колличестве одновременных запросов. Дело то не в типе бд, а в том что много одновременных запросов не пролезет через диск — только память. ваши 600к запросов то не с диска же все-таки?
например kyoto cabinet умеет искать по префиксам ключей — так можно вынуть весь список нобходимых ключей.
Да noSql начинает тормозить когда упирается в диск. но использование hs никак от этого не уберегает: он так же встанет на большом колличестве одновременных запросов. Дело то не в типе бд, а в том что много одновременных запросов не пролезет через диск — только память. ваши 600к запросов то не с диска же все-таки?
у нас имеется большой опыт его использования для решения задач с преобладанием функции записи, где под действительно большой нагрузкой проявляется ряд нюансов.с этого места и поподробнее.
Как после insert'а получить значение auto increment id?
В вашем случае MMR скорее всего применима, но в общем случае — MMR в Mysql нельзя использовать в нагруженном сервисе: помимо специфики автоинкремента есть еще не решаемые проблемы конкурентных апдейтов одних и тех же записей.
Еще цифры в тестах очень большие: у нас на серваке трехлетней давности общее время запроса (коннект/индекс/запрос) — 0.6ms те в 10 раз меньше. причем это еще далеко не предел — есть куда крутить настройки.
на нашей базе в 12 миллионов записей и 3к запросов в секунду все 3 операции занимали примерно однинаковое время — по 0.2ms — так что у вас еще и косяк где-то на коннекте происходит. не может коннект выполнятся дольше всех остальных операций
Еще цифры в тестах очень большие: у нас на серваке трехлетней давности общее время запроса (коннект/индекс/запрос) — 0.6ms те в 10 раз меньше. причем это еще далеко не предел — есть куда крутить настройки.
на нашей базе в 12 миллионов записей и 3к запросов в секунду все 3 операции занимали примерно однинаковое время — по 0.2ms — так что у вас еще и косяк где-то на коннекте происходит. не может коннект выполнятся дольше всех остальных операций
Позволю не согласиться. MMR можно и нужно использовать, ка ки любые технологии, если делаешь это с умом.
— Конкурентные update — организуйте и подумайте над данными и структурой изменения так, чтобы изменения одной записи делались на одном из мастеров.
— Автоинкремента проблемы нет никакой это сказка в mysql нативная настройка offset & total задаем число инстансов и офсет даем каждому инстансу, наслаждаемся.
— Про время операций, вы видимо про native mysql говорите цифры, не так ли? в HS порядки цифры в 10-100 раз выше в частности на connect, изза того что он дерагет напрямую сразу первичный ключ, без проверок авторизации, без разбора sql и т.п. и именнов этом выйгрыш, вы на своем старом сервере hs то поднимите и подергайте запросы, только по первичному ключу, удивитесь.
— запись на диск в mysql будет работать быстрее чем в любом быстросамописном nosql, по крайней мере я пока придерживаюсь такой позиции. пока сам не увижу обратного, хотябы потому что mysql уже лет 10 занимаетс оптимизацией записи на диск, а в nosql как правило просто тупо пишем на диск не используя ничего для оптимизации.
— Конкурентные update — организуйте и подумайте над данными и структурой изменения так, чтобы изменения одной записи делались на одном из мастеров.
— Автоинкремента проблемы нет никакой это сказка в mysql нативная настройка offset & total задаем число инстансов и офсет даем каждому инстансу, наслаждаемся.
— Про время операций, вы видимо про native mysql говорите цифры, не так ли? в HS порядки цифры в 10-100 раз выше в частности на connect, изза того что он дерагет напрямую сразу первичный ключ, без проверок авторизации, без разбора sql и т.п. и именнов этом выйгрыш, вы на своем старом сервере hs то поднимите и подергайте запросы, только по первичному ключу, удивитесь.
— запись на диск в mysql будет работать быстрее чем в любом быстросамописном nosql, по крайней мере я пока придерживаюсь такой позиции. пока сам не увижу обратного, хотябы потому что mysql уже лет 10 занимаетс оптимизацией записи на диск, а в nosql как правило просто тупо пишем на диск не используя ничего для оптимизации.
1.конкурентные апдейты — ну вы же согласны, что надо за ними очень тщательно следить и, на мой взгляд, лучше вообще отказаться от MMR в пользу шардинга — как-то спокойнее.
2. Ну согласитесь же, что настройка автоинкреимента на автоинкремент 2+1 выглядит каким-то костылем. И что вы будете делать, когда у вас появится 3я площадка?
3. про время операций: я тестировал hs на mysql 5.5. естественно мне было интересно, какой же прирост по сравнению с native mysql — прирост был примерно в 20% Это объясняется даже в статье автора плагина (той самой, про 750к запросов), что в mysql 5.1 было куча локов еще до innodb, которые они, чтением напрямую из innodb обошли. В 5.5 их очень много выпили, поэтому разница сильно сократилась. Согласитель же, что парсинг запроса и проверка авторизации это не тотальные по быстродействию операции. и не могут они занимать 90% времени запроса. Вы сами говорите, их же 10 лет разрабатывают.
4. про запись на диск. Частично согласен, но модель Редиса — переодические снапшоты + лог апдейтов мне кажется более быстрым чем синк страниц мускула в рандомном порядке
2. Ну согласитесь же, что настройка автоинкреимента на автоинкремент 2+1 выглядит каким-то костылем. И что вы будете делать, когда у вас появится 3я площадка?
3. про время операций: я тестировал hs на mysql 5.5. естественно мне было интересно, какой же прирост по сравнению с native mysql — прирост был примерно в 20% Это объясняется даже в статье автора плагина (той самой, про 750к запросов), что в mysql 5.1 было куча локов еще до innodb, которые они, чтением напрямую из innodb обошли. В 5.5 их очень много выпили, поэтому разница сильно сократилась. Согласитель же, что парсинг запроса и проверка авторизации это не тотальные по быстродействию операции. и не могут они занимать 90% времени запроса. Вы сами говорите, их же 10 лет разрабатывают.
4. про запись на диск. Частично согласен, но модель Редиса — переодические снапшоты + лог апдейтов мне кажется более быстрым чем синк страниц мускула в рандомном порядке
мускул, очевидно, синкает не в рандомном порядке, ну и плюс ядро сортирует страницы и пытается писать последовательно, а там дальше софт в самом диске, ncq всякое.
насчет редиса: упс случается, когда много пишут + запускается процесс снапшота или rewriteaof, особенно, если редис заполнен близко к общему размеру памяти на машине.
если повезет и настроена overcommit memory, то он сможет форкнуться без свопа, но т.к. записи много, и папке и дочке нужно еще памяти они оба вываливаются в своп и машина умирает. Предполагаю по этой причине народ извращается с 16 инстансами редиса на машину по 4 гига максимум каждый.
насчет редиса: упс случается, когда много пишут + запускается процесс снапшота или rewriteaof, особенно, если редис заполнен близко к общему размеру памяти на машине.
если повезет и настроена overcommit memory, то он сможет форкнуться без свопа, но т.к. записи много, и папке и дочке нужно еще памяти они оба вываливаются в своп и машина умирает. Предполагаю по этой причине народ извращается с 16 инстансами редиса на машину по 4 гига максимум каждый.
я делаю апдейты в рандомные старницы памяти. соответственно они должны быть синкануты на диск. Хорошо что ядро может их отсортировать в нужном порядке. но апдейты мускула идут в разные страницы, а апдейты редиса в одну. одну страницу синкать явно сильно быстрее чем разные.
я так понимаю, что редис надо использовать на малой нагрузке на запись чтоб не вылести в своп из-за copy-on-write? те в качестве кеша?
я так понимаю, что редис надо использовать на малой нагрузке на запись чтоб не вылести в своп из-за copy-on-write? те в качестве кеша?
Еще цифры в тестах очень большие
На всякий случай отмечу, что это цифры из продакшена.
Плюс у меня пара вопросов:
1. Как и чем вы измеряли общее время запроса (коннект+индекс+запрос)?
2. Доступ к «машине трёхлетней давности» осуществлялся с удалённого хоста или локального?
Я вот почему про это спрашиваю — различие в 10 раз по скорости это, скорее всего, по причине различия способов измерения или условий работы с HS.
заменив его хорошо зарекомендовавшей себя “master-master” репликацией между площадками
Меня интересуют два вопроса:
1. как вы делаете «master-master» репликацию между mysql базами?
2. как синхронизируются дынные между территориально удаленными серверами?
Можно об этом рассказать или хотя бы дать источники. Сколько я этим не интересовался. Везде говорили, что «master-master» в mysql дает кашу в данных. А на территориально удаленных серверах есть задержка.
1. в реплицируемой таблице есть автоинкрементный праймари.
на одном сервере:
auto_increment_increment = 2
auto_increment_offset = 1
на другом:
auto_increment_increment = 2
auto_increment_offset = 2
соответственно в первом получаем нечетные, а во втором четные записи и никакой каши.
2. наверное, я не понял вопроса. Синхронизируем именно «мастер-мастер» репликацией. Задержку в доли секунды специально не замеряли (красивых графиков ради), т.к. на фоне старого решения это однозначно на порядки быстрее.
на одном сервере:
auto_increment_increment = 2
auto_increment_offset = 1
на другом:
auto_increment_increment = 2
auto_increment_offset = 2
соответственно в первом получаем нечетные, а во втором четные записи и никакой каши.
2. наверное, я не понял вопроса. Синхронизируем именно «мастер-мастер» репликацией. Задержку в доли секунды специально не замеряли (красивых графиков ради), т.к. на фоне старого решения это однозначно на порядки быстрее.
Ответ тут
Мне вот что интересно — у вас синхронная репликация получилась на МайЭскуэеле?
1. А я думал, что такой способ не используют в крупных проектах. Часто вижу комментарии, где это называют костылем.
С вопросом я немного не так выразился. Как я понял в данном случае базы синхронизируются на прямую, как бы они это делали и в условиях расположения на одной стойке.
А как вообще синхронизируются данные (базы, файлы) между дата центрами? Ведь, например, знать о определенном юзере (его аватарке, настройках и.т.д) порой нужно в обоих центрах. Да и запись в них тоже по идее может быть из любого места. Что будет при одновременной записи в двух местах.
С вопросом я немного не так выразился. Как я понял в данном случае базы синхронизируются на прямую, как бы они это делали и в условиях расположения на одной стойке.
А как вообще синхронизируются данные (базы, файлы) между дата центрами? Ведь, например, знать о определенном юзере (его аватарке, настройках и.т.д) порой нужно в обоих центрах. Да и запись в них тоже по идее может быть из любого места. Что будет при одновременной записи в двух местах.
В общих чертах система межплощадочной репликации выглядит так:
1. Все запросы, изменяющие данные на шардах, логгируются.
2. Периодически (минимум раз в минуту) все залоггированные на шардах запросы собираются, упаковываются и пересылаются на другую (другие) площадки.
3. На площадке-получателе запросы применяются к соответствующим бэкап-шардам.
Данная система репликации написана на PHP, очень проста и надёжно работает на протяжении нескольких лет, обеспечивая минимальную задержку между обновлением данных на мастер-шарде и его репликах. Да, мы очень любим PHP и умеем хорошо с его помощью делать даже те задачи, которые, как некоторым кажется, с его помощью делать нельзя / не получится.
1. Все запросы, изменяющие данные на шардах, логгируются.
2. Периодически (минимум раз в минуту) все залоггированные на шардах запросы собираются, упаковываются и пересылаются на другую (другие) площадки.
3. На площадке-получателе запросы применяются к соответствующим бэкап-шардам.
Данная система репликации написана на PHP, очень проста и надёжно работает на протяжении нескольких лет, обеспечивая минимальную задержку между обновлением данных на мастер-шарде и его репликах. Да, мы очень любим PHP и умеем хорошо с его помощью делать даже те задачи, которые, как некоторым кажется, с его помощью делать нельзя / не получится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция архитектуры: от «самописных» сервисов к HandlerSocket