MemSQL разогнал базы данных в 30 раз

Runa на них нет!

[URL=http://habrahabr.ru/post/146023/]в каментах[/URL] минутка объективности

Какая уж там объективность. На любой подобный материал найдутся «раскрывающие заговор». И столько их, что не продохнуть Земле Русской от талантов. Но! От чего-то именно «Никит» и главное результатов их творчества не так уж и много. Сколько россиян инноваторов в ПО сходу можно назвать? Я не спорю, что могут быть и впаривающие какую-то ерунду, но даже таких товарищей гораздо меньше, чем светочей объективности и профессионализма.

В YC ездили? Круто, однако — я думал, из русских там только 17-летняя топ-модель была.

Авторы взяли обычный MySQL и настроили его так, чтобы держать базу полностью в оперативной памяти. Что не является таким уж крупным инновационным достижением и ради чего могут серьёзно пострадать сами данные. Обычная настройка оптимизации, ну разве что экстремально улучшенная. Важно другое. Очевидно, что MemSQL сделан на базе MySQL, даже API менять не стали. Если изначально это была версия с открытыми исходниками, то она распространяется по лицензии GPL, а значит, необходимо открыть все исходники MemSQL по той же лицензии. Если же молодые техно-инноваторы купили лицензию Oracle, то она не позволяет менять копирайты и говорить, что это — совершенно инновационная разработка, а только перепродавать и вроде бы встраивать MySQL в чужие программы (без обязательства открывать исходный код). Интересно, как на этот пресс-релиз отреагирует законный правообладатель, корпорация Oracle?

>Что не является таким уж крупным инновационным достижением и ради чего могут серьёзно пострадать сами данные. Она записывает на диск данные сразу после выполнения транзакции в памяти. и в чём тут сильная разница? обычная база если упадёт в середине транзакции, то тоже данные не запишутся.

А если база упадёт в середине сохранения снапшота?

Чьи юристы возбудятся раньше — Oracle или Microsoft?

Прочитал маркетинговый опус и не смог ответить на вопрос: а почему ускорение именно в 30, а не, скажем, в 100 раз? Узкое место серверов баз данных это всегда диски (при крупных объемах информации). Существенного прогресса в ускорении программной части работы с диском сейчас можно добиться, только снизив уровни транзакций. Последствия этого шага могут быть весьма печальны, особенно если это сделано в тихую, без явного информирования конечного пользователя. Некоторое ускорение может дать собственная файловая система, как это есть у Oracle. Но это ускорение по сравнению с хорошо настроенной файловой системой невелико (даже до двух раз не дотягивает, не говоря уже о 30-и). Другой вариант это оптимизация работы с кластерами, т.е. создание эффективных алгоритмов аудита и оптимизации данных при кластерной архитектуре. Но кластерные решения обычно узкоспециализированы и поэтому, создание универсального кластерного сервера баз данных, которое даст «ускорение в 30 раз», выглядит сомнительно. Третий вариант программного ускорения это создание эффективных алгоритмов кеширования. Универсального решения тут нет. Задача кеширования уже имеет и богатую научную историю, и прикладную, и практическую, ничего радикально нового («ускорение в 30 раз») на имеющейся технологической базе здесь появиться не может. Если этот проект имеет цель добиться «ускорения в 30 раз», а не просто освоить деньги, то возможно, по своей сути, это просто эффективная, абстрагированная от логики mysql, настройка сервера баз данных под несколько конкретных задач. В этом случае, ускорение в 30 раз по сравнению с ненастроенным сервером добиться можно. В этом случае, для хороших специалистов memSQL не даст ничего нового.

Решение можно скачать и опробовать. Там есть форма заказа.

Мне кажется, новость не для роема. Здесь нет той экспертизы, которая есть на том же хакер ньюс, для которого эта новость как раз.

Не любите считать чужие деньги?

> Мне кажется, новость не для роема. Здесь нет той экспертизы, которая есть на том же хакер ньюс, для которого эта новость как раз. Так тут и экспертизить нечего. Дали $3*10^6 на тему разработки софта ускоряющего работу с диском в 30 раз. Вопрос почему? А это как раз сфера профессиональной квалификации аудитории роема.

> Она записывает на диск данные сразу после выполнения транзакции в памяти Наоборот же намного надежнее? Неужели такой выверт может дать выигрыш в скорости настолько, что оправдывается?

> Наоборот же намного надежнее? Неужели такой выверт может дать выигрыш в скорости настолько, что оправдывается? Что когда и куда пишется очень строго прописано в правилах проведения транзакций. Как только от этого отступают начинаются сюрпризы. А сюрпризы в бд это всегда плохо. Выйгрыша в скорости от этого не должно быть. Скорее даже некоторый проигрыш. При настройке бд нужно учитывать три кеша: бд, файловой системы, дисковой системы. Если все принудительно пихать в кеш бд, то будет эффект двойного кеширования, ибо файловая система и так все кеширует, и даже пишет на диск изменения, если есть свободные ресурсы.

soomrack, белим по тшорний написано — оперативные данные в памяти, хранение на диске, память быстрее диска на порядок(ки) + бинарный код вместо интерпретатора для запроса, отсюда и 30 раз. Жаль, что нет сравнения с ndb.

dima5ty, если вы так детально изучили memSQL объясните, пожалуйста: 1. Какого уровня транзакции: 0 (как я подозреваю) или 1 (при том, что банковского сектора нужен как минимум 2-й)? В точности ли выполняется порядок операций с данными, описанный в соотв. уровне транзакции? 2. Как разработчики обошли эффект двойного кеширования, если у них все находится в кеше сервера бд? 3. В чем работа memSQL с точки зрения работы с данными в оперативной памяти, эффективней чем обычный кеш файловой системы (например, xfs)? 4. Расскажите, пожалуйста, что происходит с целостностью данных при внезапном выключении сервера (отказе райд-контроллера и т.п.). И хотелось бы у видеть конкретные примеры тестов с ускорением в 30 раз, в рекомендуемых конфигурациях (+размер бд в 8-10 раз больше размера оперативной памяти), для распространенных бенчмарков, типа pgbench (для postgresql): количество транзакций в секунду и латентность системы в зависимости от кол-ва клиентов.

https://s3.amazonaws.com/whitepapers.memsql.com/memsql_technical_overview.pdf

Ну если вдруг начну в ней участвовать, так сразу всё и расскажу, а пока можете почитать документацию на интересующие темы http://developers.memsql.com/docs/1b/index.html И вопросы ваши какие-то не про то всё.

В этом документе ничего конкретного не сказано. Ответов на мои вопросы, заданные в предыдущем комментарии, там нет (а транзакции — это первое, про что нужно узнавать для новых серверов бд). Единственное, что там прямо сказано, так это то, что поддерживает неблокирующее чтение, все, больше конкретики там нет. Зато много слов о тысячах на обычном компьютере и миллионах на кластере транзакций в секунду.

dima5ty, вопрос что будет с целостностью моих данных в новом сервере это самый главный вопрос. Обеспечивать целостность данных это главная задача сервера баз данных. Поэтому мои вопросы по технической части самые актуальные. По указанной ссылке про транзакции есть только этот текст: The only currently supported isolation level in MemSQL is READ COMMITTED. The SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL syntax is supported for compatibility with MySQL but has no effect on MemSQL and will result in an unsupported feature warning (see Unsupported Features). MemSQL supports snapshot isolation level for use by internal system transactions used to build database snapshots, but transactions at this isolation level are not exposed to user transactions. MemSQL only supports single query transactions. Every query begins and commits in its own transaction. The START TRANSACTION, BEGIN, COMMIT and ROLLBACK syntax is supported for compatibility with MySQL, but it has n o effect and will result in an unsupported feature warning (see Unsupported Features). В котором ничего не сказано об уровне транзакций. Вообще! Из документации следует, что сейчас есть только подтвержденное чтение. А целостность обеспечивается только на уровне ОДНОЙ команды.

PS: На всякий случай поясню, целостность на уровне одной команды, в частности, не позволяет гарантировать целостность операции перевода денег между счетами: «снять деньги со счета №…» + «зачислить деньги на счет №…». Это минимум две команды. Текущая версия memSQL (согласно документации) не позволяет выполнить транзакцию «перевода денег», т.е. в случае сбоя может так оказаться, что деньги сняты, но не зачислены, и наоборот.

Лет шесть назад рабтал в компании где так Firebird разгоняли для внутренних целей. Там было еще круче чем хранение целиком таблиц в памяти… Вся сложность была — сделать такую версию FreeBSD в которой много-гигабайтные электроные-диски можно поддерживать…

soomrack, еще раз, все структуры в памяти. Диска, чтобы писать снапшоты и логи хватает. Такая милая inmemory database, если у вас данных не больше гигабайт. Для тех, кому нужен хэш векторов в памяти, но писать на C++ лень. Странная ниша. Решение абсолютно одномашинное.

Alter Ego, я не знаю как в MsSQL (с ней не работал), но в PostgreSQL, MySQL, Oracle если у вас база меньше объема оперативной памяти, то она и так вся будет в кеше. Изменения и wal на диск будут писаться в соответствии со строгими правилами проведения транзакций. В чем может быть выйгрыш по скорости без потери надежности в этом случае мне непонятно. Например, на моем стареньком домашнем компьютере для маленькой бд postgres выжимает до 35.500 транзакций в секунду, если база целиком помещается в память; если нет, то падает до ~940 tps (работа со случайными данными, размер бд в 10 раз больше размера оперативной памяти, pgbenсh). И я не могу представить себе как в принципе 35.500 можно увеличить в 30 раз (т.е. до 1.000.000 tsp). Или как 940 можно увеличить до 30.000 tps — пиковый показатель, когда вся бд в оперативке. [ирония] Если сервер бд данные можно было бы поместить в первый кеш процессора, то ускорение только по сравнению со случаем всей бд в DRAM будет в 200 раз! А с диском, соотв. в 6000! [/ирония]

>Oracle если у вас база меньше объема оперативной памяти насколько меньше? там же кэшей миллион, и под данные выделено далеко не всё.

Ну конечно можно. hash_map в памяти может и 5M обращений в секунду выдержать в один тред. В случае SQL расходы на парсинг таких запросов будут больше, чем стоимость обращения, но даже в случае SQL, 100K выжать можно. Да, их 20x раз в демке — это фэйк, точнее mysql «из коробки». Но 3x раза получить можно, думаю, на простых запросах за счет адаптации под размещение данных в памяти. Про кэш процессора — смешно. Вам срочно нужно в долину, $5M ждут вас :)

Alter Ego, все кеши нужно настроить. Настройка «из коробки» обычно позволяет запустить сервер на любом компьютере. и поэтому, мягко говоря, не оптимальна. Насколько меньше — зависит от настроек. Если у вас действительно бд всегда будет меньше размера оперативной памяти, то можно выдать под кеш данных объем чуть превышающий размер бд. Если нет, то обычно рекомендуется (и по моему опыту это оптимально) давать 25% от RAM под кеш данных, думая о том, что 50% RAM отдать под кеш фс, + еще будет 512Mb+ кеша от raid’а (а в нем еще 64Mb х кол-во дисков кеша от дисков), это если все хорошо с питанием и используется write-back. Настройка сервера бд начинается с настройки железа и файловой системы. Уже на этом этапе можно достичь ускорения в 4-5 раз по сравнению настройкой по умолчанию, при той же надежности. Потом настройка сервера бд. Сравнивать оптимизированное с настройками «по умолчанию» некорректно. Тут показатели могут быть любые и в 100 и в 1000 раз, ибо настройки по умолчанию это минимум который нужен для запуска, но не для работы. Потом аудит данных: индексы, нормализация, сегментирование (иногда используется термин «парционирование»)… Потом аудит работы с сервером бд и ее оптимизация: в частности делать подготовленные и прекомпилированные команды (postgresql, oracle — точно есть), команды, которые часто повторяются, оформлять как view, для лучшего кеширования и т.д. Причем почти на каждом этапе можно получать ускорения в 1000+ раз, только при этом говорить, что мы ускорили базу в 1000 раз — некорректно.

Ну демка MemSQL открыта на github. Выжмете из postgre или mysql 100K на бюджетном серверном железе? :)

Это было бы эффектно. Суровые русские мужики сказали «ух», и…

> Ну демка MemSQL открыта на github. Выжмете из postgre или mysql 100K на бюджетном серверном железе? :) Учитывая, что 35.000+ у меня на домашнем компьютере 5-летней давности (и тогда он тоже был далеко не топ), то на сегодняшнем бюджетном сервере, наверное, можно выжать 80.000+ tps (может быть и 100.000+ tps, если сервер не совсем бюджетный), по pgbench. Но вся проблема в тестах, я не видел детального описания тестов для memSQL. Если я одну и ту же атомарную команду, работающую с одними и теми же данными буду выполнять на постгресе то я смогу выжать и 1.000.000+ tps, только грош цена такому показателю.

https://github.com/memsql/workload-simulator

Спасибо. Тест не стандартный (не широко используемый), с ним надо разбираться. Посмотрю позже.

soomrack, напишите о результатах — будем следить за комментами

soomrack?

Вот бывший сотрудник MySQL (Domas Mituzas) написал примерно про тоже что и я (это маркетинговая лажа, сравнение с настройками «по умолчанию», непонятки с транзакциями, …). Есть конкретные примеры: SELECT * FROM table ORDER BY id DESC LIMIT 5; В MySQL этот запрос будет быстрым и не потребует загружать всю таблицу в память, а в MemSQL — будет учень медленно, ибо будет (зачем?) загружать всю таблицу в память. Про транзацкии: I don’t know how much we should be blaming MemSQL guys and how much that should be directed at journalists that were hyping on the technology. If we get back to ACID, we’d see that A for atomicity is done only at statement level and BEGIN/COMMIT are ignored. Isolation is only READ COMMITTED (difficult to have REPEATABLE READ with no real transactions). Durability is flawed, and I didn’t check C part. I got to admit, MemSQL FAQ states that “Yes, MemSQL supports fully ACID transactions”. This is on them, then.

Ссылку забыл поставить: http://dom.as/2012/06/26/memsql-rage/