MySQL в миллион раз быстрее MemSQL

    Пару дней назад по мировой технологической прессе распространился пиар MemSQL — базы данных нового поколения от Никиты Шамгунова (shamg), которая якобы показывает скорость в 30 раз выше, чем MySQL и при этом «надёжна по дефолту» (durable by default), как сказано у них на сайте.

    Представители MySQL не снизошли до ответа на эти очевидные маркетинговые лозунги. Но вот бывший сотрудник MySQL, Домас Митузас (Domas Mituzas), ныне специалист по базам данных в Facebook и Wikipedia, всё-таки не выдержал и решил разобраться, как именно нас обманывают — и ответить тем же, то есть показать примеры, где MemSQL работает в сотни, тысячи и даже миллион раз медленнее, чем MySQL.

    Главный тезис о «30-кратном приросте производительности», как выяснилось, выведен из тестов производительности MySQL с параметрами по умолчанию против MemSQL с параметрами по умолчанию. Здесь уже начинается читерство, потому что системы вынуждены работать совершенно в разных окружениях: например, буфер памяти в MemSQL, фактически, ничем не ограничен, а в InnoDB он установлен на 128 МБ в MySQL 5.5 (и это в 16 раз больше, чем в 5.1).

    Для бенчмарков записи сравнивается MemSQL с логами транзакций 2 ГБ и InnoDB с логами по 10 МБ.

    В то же время для любых бенчмарков, пишет Домас Митузас, важна надёжность. В то время как InnoDB реально проверяет, что транзакции сохранены на диск, «надёжность по дефолту» MemSQL означает всего лишь, что запись занесена в лог транзакций, но на самом деле это не гарантирует, что она сохранится на диске. Транзакционный буфер MemSQL работает примерно как режим innodb_flush_log_at_trx_commit=2. Если же включить полную защиту транзакций в MemSQL, то это будет душераздирающее зрелище: фоновый процесс просыпается каждые 50 мс для записи лога транзакций.

    Итак, что же получается в итоге? MemSQL работает в 500 раз медленнее в режиме надёжных транзакций.

    В режиме чтения MemSQL способна сканировать 8 млн строк в секунду по запросу SELECT COUNT(*), это великолепный результат. Но вот запрос:

    SELECT * FROM table ORDER BY id DESC LIMIT 5;

    Такой запрос встречается повсюду, он показывает топы разных списков. MySQL выполняет его, нормально перемещаясь по индексу от записи к записи, в то время как MemSQL вынуждена перемолоть всю таблицу целиком и отсортировать её заново для выполнения запроса. Даже запрос SELECT MAX(id) приводит к обходу всей таблицы целиком.

    Итак, MemSQL в тысячу раз медленнее MySQL, или в миллион раз медленнее. На простых запросах на чтение.

    В общем, Домас Митузас делает вывод, что MemSQL — отличная разработка и быстрейший протокол MySQL из существующих, для некоторых задач, но он не так уж сильно опережает MySQL Cluster, да и разработчики NDB Cluster тоже заявляют об очень высокой производительности. Однако, MemSQL нуждается в правильной оптимизации для более типичных паттернов использования.
    Поддержать автора
    Поделиться публикацией

    Комментарии 50

      +4
      Так а в чем цель разработки memSQL?
        +28
        Инвестиции?
          +2
          Может лучше спросить у Никиты Шамгунова? Может у него найдётся что ответить?
            –8
            Статья Домаса — реакция на наше заявление — «самая быстрая БД в мире». Конечно все зависит от того какой набор данных и запросов… Вот мой ответ на хакер ньюз
            news.ycombinator.com/item?id=4163054

            1. select * from t where id > 10 limit 10; — здесь нужно использовать убывающий индекс. домас это стразу не понял.
            2. для видео мы использовали синхронную надежность, а для memsql — асинхронную. но это настройки по умолчанию.
            3. синхронная надежность в memsql гораздо медленнее, чем асинхронная. мы оптимизировали для буфера 128 мегабайт. Мы будем улучшать ее в следующем релизе.
            4. У нас не опубликованы бенчмарки — но мы только что запустились и нас огромное количество скачиваний, мы не ожидали подобного успеха

            А завтра выйдет статья с бенчмарками — читайте hackernews!
              +7
              то есть ваша «самая быстрая БД в мире» не самая быстрая?

              1. + 2. ты вы уж определитесь по умолчанию — тогда нечего индекс себе добавлять или не по умолчанию, тогда в одинаковые условия ставьте обе БД
              4. т.е. опять же голословно самая быстрая?
                +1
                Самая быстрая по transactions/second при условии небольших транзакций: OLTP
                1. Так мы-ж определились по умолчанию. Не мы неправильно индексы создали а Домас
                4. Как я уже сказал — бенчмарки завтра.
              +9
              В большинстве случаев, когда кто-то заявляет что у него есть что-то «лучшее в мире», обычно оказывается что он про просто не в курсе что в мире творится.

              Я к тому что надо точнее быть в громких высказываниях, а то будет сначала шумиха, а потом дикий срач.
      • НЛО прилетело и опубликовало эту надпись здесь
          +6
          А оно так преподносится, что в разряд вранья не попадает, поэтому наказать не получиться. Вспомним хотя бы такую штуку как заявленные объем флоппик дискеты в 1.44 Мб (диска/флешки/прочее).
            +1
            Про брехливую рекламу согласен — очень не хватает законодательно базы для карания таких рекламщиков, но пример не совсем корректен.

            Согласно стандарту IEC 1MB для носителей информации кроме дискеты(там исключение) 1MB = 10^6байт.
            Таким образом заявленные десятичные 40GB = 40*10^9 = 37.2 GiB(настоящих).

            Это стандарт и это нужно понимать. Для избегания двусмысленности можно использовать GiB/MiB итд. Они бинарные и кратны 1024 а не 1000.
              +1
              Пример как раз максимально корректный. На нем хорошо виден общий механизм. Законодательной базы тут не может быть, т.к. рекламщики всегда найдут такую формулировку при которой реклама не будет обманом («а у нас байты в десятичном исчислении, какие проблемы?»), но по факту такой является будет (ибо ну не будут разбираться пользователи в тонкостях счислений).

              Вот берем пример. Пользователь на дискету попытается записать файл 1.3 Мб который меньше же чем заявленных 1.44. Но файл не запишется, ибо реальный объем ниже. Казалось бы, факт обмана на лицо. Но привлечь за это не получится, рекламщики буду упирать на то, что указали размер в десятичном исчислении. И будут правы. А пользователю эти тонкости до фонаря и он купит дискету в 1.44 Мб, а не 1.38 МиБ.
                –1
                Дело в том что «М» это не приставка мега, которая обозначает 10^6 а просто буква М.
                Приставка мега(которая 10^6) это буква «м».
                Приставка «Ми» и её семейство введено позже, как раз для избавления от таких проблем.
                  –1
                  буква М как раз из семейства бинарных, т.е. 1024
                    0
                    А в LVM2 — наоборот… 1077M vs 1028m
                    +1
                    я перепутал :( это касается только кило. а мега — действительно одинаково обозначается.
                      –1
                      > Приставка мега(которая 10^6) это буква «м».

                      Докатились :-(
                      Буква «м» — это приставка милли!
                        –2
                        я же это уже написал. Я перепутал с «к».
                  +3
                  Сегодня маркетологи Киевстара взорвали мне мозг следующей записью:
                  «Тарификация… звонков… является посекундной и осуществляется в первую секунду каждой минуты разговора, секунды со второй по шестидесятую каждой минуты разговора не тарифицируются.»
                  +3
                  СУБД будет пользоваться специалист. Вот он и выберет.

                  А если у вас технологии специалистам спускают сверху менеджеры… Ну что сказать, бежать надо из таких мест.
                    +12
                    Имеется в виду, что специалист должен быть лично знаком с каждым из продуктов на рынке, чтобы выбрать оптимальный для предполагаемых сценариев использования. Или должен лично тестировать. Не исключено, что в итоге выбор оптимального продукта окажется дороже чем использования первого попавшегося, «спущенного менеджерами» например. Скажем если использование MySQL будет обходиться 1$ в день, а какого-нибудь OptimalSQL 0,5$, но для установления этого факта нужно будет потратить неделю времени специалиста с зарплатой 100$ в день, то окупится этот оптимальный выбор лишь через 3 года.
                      –8
                      если специалисту для примерно такого же бенча, о котором в этом посте речь, требуется более одного рабочего дня, то либо это джуниор с соответствующией з/п, либо его надо гнать ссаными тряпками.
                        +2
                        Кто говорит о примерно таком же? Возьмите лог запросов какой-нибудь сложной систмы и посчитайте сколько там типов запросов. А зарплата джуниора в цивилизованных странах может и быть повыше чем 100$ в день (~24 000$ в год).
                          0
                          Я говорил исключительно в контексте memsql. Человеку, который вообще понимает, какие в СУБД бывают индексы с точки зрения структур данных, достаточно прочитать страницу developers.memsql.com/docs/1b/indexes.html — этого вполне достаточно, чтобы понять, в каких (узких) случаях memsql применим, не проводя вообще никаких тестов.

                          Разумеется, сравнение производительности, скажем, MySQL/InnoDB vs PostgreSQL невозможно даже по query log: для разных СУБД запросы — и даже архитектура базы — будут совершенно разными. Здесь нужно исходить из основных потребностей по фичам, после чего хороший DBA поможет решить задачу на любой СУБД.
                        0
                        Ещё как окупится в сэкономленных часах на отладку, поиске багов.
                        +3
                        Увы но в больших компаниях где платят деньги и не заставляют делать ничего кроме своей работы все приходит сверху, а там правят маркетологи, им значима цена и возможный откат, а также красивые бумажечки и сертификаты…
                          0
                          … а также
                          стоимость владения
                          стоимость поддержки
                          стоимость обучения новой системе
                          стоимость часа простоя продакшена
                        +3
                        Поддерживаю. Бывает так распиарят продукт, а купишь его и пытаешься использовать в продакшене — всё сыпется.

                        Кстати есть же различные рейтинговые агентства которые ставят прогнозы и рейтинги экономике различных стран. Также и тут независимое агентство которое занимается оценкой производительности, интерфейса, динамики развития различных продуктов.
                          +2
                          я бы посмотрел на отчаянных парней, использующих в продакшене только что вышедшую первую публичную версию какого бы то ни было продукта ;)
                        +7
                        «запрос SELECT MAX(id) приводит к сортировке всей таблицы целиком.»
                        Это очень, очень грустно.
                          +5
                          Помоему это ошибка перевода.
                          в оригинале написано, что «SELECT MAX(id)» обходит всю таблицу. («crawl»)
                            0
                            Действительно, уже исправлено. А я уж было удивился.
                          +4
                          Очень рекомендую посмотреть вот это видео про MySQL на ADD2012.
                            +3
                            в то время как MemSQL вынуждена перемолоть всю таблицу целиком и отсортировать её заново для выполнения запроса

                            Объясните пожалуйста, почему?
                              +5
                              В комментах появился CTO MemSQL. Для индексов у них используется не B-Tree, а однонаправленные skip lists. Для любых операций, которые производятся в порядке, обратном индексу, им приходится перемалывать всю таблицу
                                +1
                                Там вроде можно второй индекс в другую сторону создать.
                                +1
                                Есть предположение, что индекс или структура хранения использует хэширование, которое полезно в случае выборок а-ля =, IN(), !=, а на выборках вроде <, >, BETWEEN, etc роли никакой не играет, поэтому и происходит фуллскан. Но это только моё предположение.
                                  0
                                  тьфу, буду обновлять комменты прежде чем писать…
                                +8
                                Дал отпор. Уважаю таких и ненавижу PR.
                                  +13
                                  Зато бесплатно протестировали. Можно оптимизироваться и запускать второй этап тестирования рекламной кампании. А иначе как бы они Мутизаса да забесплатно заставили бы тестировать? ))))))
                                    +1
                                    Учитывая, что большинство людей впервые услышало о MemSQL после поста Домаса, авторы продукта должны быть на него не в обиде ) Имхо, уже само название MemSQL — хороший маркетинговый ход. Думаю, для многих задач штука будет крайне нелишней.
                                      +5
                                      Палка с двух концов.

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

                                      Это примерно, как Ford Focus. Была о нём маркетинговая реклама на грани вранья, но большинство её так и не видели. После же появилась куча негативных отзывов и теперь здравомыслящий водитель обойдёт эту машину стороной. Справедливости ради, салон Ford недалеко от дома сейчас предлагает акцию «Новый Focus каждые четыре года». С одной стороны не плохо, но с другой — что же это за гроб на колёсах, если придётся менять каждые 4 года, когда большинство автомобилей служат 8 — 12 лет.
                                        +5
                                        Не хочется начинать тут оффтопиковый холивар, но новые (современные) машины 8-12 лет не служат (по крайней мере, на это не расчитано). После 4х лет и 100К пробега наступает резкое снижение надежности и постоянно приходится что-то менять (или продать тому, кто об этом не знает или готов смириться).

                                        И да, Ford Focus, отличная машина для своего класса, во многих странах, кроме России. В России своя линия сборки и на выходе получается почти ВАЗ, а рекламу видимо с Запада адаптировали, где получается вполне приличная машина.
                                          –13
                                          А ЗАЧЕМ мне одна и та же машина 10 лет подряд??? Вы же майки не носите 10 лет надеюсь :)
                                            +10
                                            А зачем выкидывать машину или майку и покупать новые, если они ещё в исправном состоянии? Есть, конечно, люди для которых слова «мода» или «понты» не пустой звук…
                                              +2
                                              А я вот не понимаю как люди машины постоянно меняют. К машине ж привязываешься, продавать просто жалко (конечно, если не раздолбана вусмерть). А уж если в ней собственноручно какие-то изменения сделаны (CarPC, к примеру) и вообще сама идея продажи кощунствена.
                                          –6
                                          Знаете, что я понял? У вас неипацо чекнутый дизайнер.
                                            0
                                            Сайт у них нормальный (www.memsql.com) вы видимо ругаете сайт YCombinator, что собственно к теме не имеет никакого отношения ;)
                                            +2
                                            ХЗ. У парня по ссылке карма -1. Плюсану а потом разберусь, что за хитро**** пиар такой
                                              +2
                                              Forbes уже поспешили включить memSQL в The Big Data Landscape.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое