Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
очередной убийца i… mySQL?
А смысл? Вопрос не риторический.
Примерно с этими же целями давно уже делаем следующим образом: временный диск в памяти на нужный объем, мускульные файлы располагаем на этом диске, все. Если нужна надежность в плане «сервер ребутнулся внезапно» — делается репликация в БД располагающуюся на диске и/или пишутся на диск бинарные логи.
Опять же, memory table никто не отменял (пусть даже их применение весьма ограничено).
Кстати интересно, в случае внезапного ребута что будет с данными в этой базе?
Примерно с этими же целями давно уже делаем следующим образом: временный диск в памяти на нужный объем, мускульные файлы располагаем на этом диске, все. Если нужна надежность в плане «сервер ребутнулся внезапно» — делается репликация в БД располагающуюся на диске и/или пишутся на диск бинарные логи.
Опять же, memory table никто не отменял (пусть даже их применение весьма ограничено).
Кстати интересно, в случае внезапного ребута что будет с данными в этой базе?
MemSQL позволяет восстанавливать все данные с диска. Она записывает на диск данные сразу после выполнения транзакции в памяти. Используется комбинация логирования и snapshot'ов.
А чем это отличается от поведения mysql?
А чем гарантируется запись?
Трудно сказать, я не видел код MemSQL.
:) На сайте написано «MemSQL ensures your data is safe and secure».
Я не разработчик этой системы и не имею никакого прямого отношения к memsql. На вопросы относительно внутренней функциональности я ответить не могу.
Я не разработчик этой системы и не имею никакого прямого отношения к memsql. На вопросы относительно внутренней функциональности я ответить не могу.
На сайте написано «MemSQL ensures your data is safe and secure».
Ну, на заборе тоже написано. Вопрос в том, чем это подкреплено.
Во-во. В документации, про транзакции мне удалось найти только такой текст:
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).
Из которого следует, что целостность данных есть только в рамках выполнения ОДНОЙ команды.
Про уровни транзакций ни слова.
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).
Из которого следует, что целостность данных есть только в рамках выполнения ОДНОЙ команды.
Про уровни транзакций ни слова.
А какой во всем это смысл? Если памяти хватает, mysql и сама ее прекрасно умеет использовать, не нужно городить огород с дисками в памяти. Тем более, что для больших объемов это не вариант (разворачивать долго + для надежного хранения надо доп. костыли городить).
Для хранения больших объемов есть поддержка масштабирование на несколько машин.
Если памяти хватает, mysql и сама ее прекрасно умеет использовать, не нужно городить огород с дисками в памятиНе всегда умеет, бывают ситуации когда разумнее кинуть на временный диск базу. Рядовая ситуация — таблица Х.Гб, а кэшируемые выборки в памяти занимают 10*Х.Гб — куда разумнее не фига не кэшировать, а разместить таблицу на временном диске.
Что касается огорода — диск в памяти с бинарными логами и/или репликацией — это рядовые и несложные операции, а главное дешевые и понятные.
для больших объемов это не вариантБытовой выделенный сервер позволит иметь 24Гб под мускульную базу, базу как правило можно несложно порезать на несколько серверов. Большие объемы понятие относительное в общем.
По сути мы этот способ использовали еще до появления мемкэшед даже, давал очень неплохую производительность практически нахаляву. С появлением мемкэшед частично отказались от него, но лишь частично, во многих случаях mysql оставить немного «хакнув» размещение баз — намного удобнее.
Ну размер кэшей можно настраивать, кроме того, кэшируются не только результаты запросов, но и сами данные. mysql умная штука. Мы тоже когда-то мучались с виртуальными дисками, синхронизациями с версией на диске и прочими ужасами. Как показала практика, лучше внетреннего кэша оно не работает, а добавляет проблем.
Премущества кэша в том, что он умеет утилизировать любой объем оперативы, не обязательно иметь ее столько, чтобы все данные влезли и еще он умеет кэшировать промужеточные данные, что разгружает процессор (если эти кэши выключить, то хоть диска и не будет, процессор для повторной сборки данных, использоваться будет всегда.
Премущества кэша в том, что он умеет утилизировать любой объем оперативы, не обязательно иметь ее столько, чтобы все данные влезли и еще он умеет кэшировать промужеточные данные, что разгружает процессор (если эти кэши выключить, то хоть диска и не будет, процессор для повторной сборки данных, использоваться будет всегда.
Кэш можно хитро настраивать, можно надеятся на мускул — это все безусловно верно.
Но память работает конкретно быстрее чем диск, это вроде как бесспорно.
И если вся база в память недорого помещается, то зачем плевать на этот простой способ ускорения работы в разы… особенно если при этом затраты памяти получаются нередко меньше чем в случае использования кэширования… а способ будучи способом грубой силы — не требует дорогих и умных и долгих специалистов на каждом этапе (от настройки сервера до программистов самой CMS).
Но память работает конкретно быстрее чем диск, это вроде как бесспорно.
И если вся база в память недорого помещается, то зачем плевать на этот простой способ ускорения работы в разы… особенно если при этом затраты памяти получаются нередко меньше чем в случае использования кэширования… а способ будучи способом грубой силы — не требует дорогих и умных и долгих специалистов на каждом этапе (от настройки сервера до программистов самой CMS).
Простой вопрос: а что происходит с данными при перезагрузке сервера, не важно, плановой или аварийной?
en.wikipedia.org/wiki/VoltDB (2 years ago)
Вот интересно. Если каждая транзакция все равно пишется на диск, то диск все равно остается узким местом. За счет чего улучшение «на порядки»? Мне приходит в голову только перераспределение нагрузки, но оно не сработает на приложений с постоянной загрузкой во-первых, и пропадет D из ACID во-вторых.
Теоретически, за счет того что данные на диск пишутся «потом» в фоновом режиме и диск не нужно ждать. Не уверен, правда, что это существенно отличается от поведения того-же mysql.
Эмм… а что делать, когда данные приходят быстрее (на пару порядков), чем их успевает записывать диск? Очередь в какой-то момент станет больше, чем сервер может записать в ближайшие n лет.
А что в этом сделает другая СУБД? Правильно, сдохнет и перестанет принимать данные;) ничего не мешает реализовать подобное поведение и тут.
Отличное решение!
Если данные превышают размеры диска — можно воспользоваться тем же трюком!!!
Если данные превышают размеры диска — можно воспользоваться тем же трюком!!!
Это означает, что никакого «увеличения прозводительности на два порядка» нет.
Ну его и быть не может. Это наверное сравнивали просто производительность диска и памяти;) тот-же mysql отлично использует память для работы и вряд ли будет медленнее этого memsql. Разве что если сравнивать первый запрос после рестарта сервера (с неразогретым кэшем) в mysql с запросом уже из памяти для memsql.
>> решающая проблемы наиболее ограничивающего для большинства нынешних приложений компонента— диска
Т.е. вот эта проблема в MemSQL заявлена как решаемая, но по факту не решается — если данных столько, что диск — всё равно — узкое место, то буфер хранения переполнится, и база сдохнет. Или я что-то не понял?
Т.е. вот эта проблема в MemSQL заявлена как решаемая, но по факту не решается — если данных столько, что диск — всё равно — узкое место, то буфер хранения переполнится, и база сдохнет. Или я что-то не понял?
Не надо забывать что для каждой задачи свой инструмент.
Если вам много писать и данные архиважные (вы не можете потерять данные более чем, ну например, за 5 минут), то возможно нужно использовать не memsql. Если нужно что-то агрессивно читать, то, опять же возможно, стоит попробовать memsql. Из документации следует что есть возможность отключения логирования и создания снапшотов.
Если вам много писать и данные архиважные (вы не можете потерять данные более чем, ну например, за 5 минут), то возможно нужно использовать не memsql. Если нужно что-то агрессивно читать, то, опять же возможно, стоит попробовать memsql. Из документации следует что есть возможность отключения логирования и создания снапшотов.
как же тогда гарантировать сохранность данных?
В общем, на сайте написано: «The transaction-buffer setting allows you to configure the maximum size of the in-memory, per-database buffer of database transactions. If this buffer fills up, write queries will block until some of it is committed to disk to make space for new transactions.»
То есть на постоянной загрузке скорость будет равна скорости диска. Кул.
То есть на постоянной загрузке скорость будет равна скорости диска. Кул.
Линейная запись на диск чуть ли не на порядок быстрее случайной, так что тут можно получить какой-то профит от писания только Write-Ahead лога. Довольно большой буфер может сглаживать пиковые нагрузки. Но что-то мне подсказывает, что InnoDB при грамотной настройке будет работать не сильно хуже, если не лучше.
В общем, велосипед, который давно написали :)
В общем, велосипед, который давно написали :)
Неужели это совпадение?
objdump -t memsqld | grep mysql
содержимое можно глянуть тут pastebin.com/pLaL3FqY
objdump -t memsqld | grep mysql
содержимое можно глянуть тут pastebin.com/pLaL3FqY
То есть вас не смутил полностью совпадающий бинарный протокол сервер-клиент, который позволяет использовать все существующие языковые биндинги для mysql по отношению к этой СУБД?
По мне так сразу это стало очевидно то, что они как минимум «унаследовали» довольно большую часть mysql.
По мне так сразу это стало очевидно то, что они как минимум «унаследовали» довольно большую часть mysql.
А что удивительного после этого:
$ mysql -u root -h 127.0.0.1 -P 3307 --prompt=«memsql> „
По сути там mysql база, которая вся держится в памяти.
Кстати, я вот подзабыл, неужели если база достаточно небольшая, mysql при должной настройке не сможет её так же целиком закешировать?
$ mysql -u root -h 127.0.0.1 -P 3307 --prompt=«memsql> „
По сути там mysql база, которая вся держится в памяти.
Кстати, я вот подзабыл, неужели если база достаточно небольшая, mysql при должной настройке не сможет её так же целиком закешировать?
Кстати, я вот подзабыл, неужели если база достаточно небольшая, mysql при должной настройке не сможет её так же целиком закешировать?Насколько мы помним (можем ошибаться) — myisam не сможет, innodb сможет.
Да, вот бы почитать на русском про такую настройку.
1. mySQL поддерживает временные таблицы — они всегда хранятся в оперативной памяти, есть ограничения по их формату, работа с ними очень быстрая (кстати, не сложно сделать периодическую синхронизацию с таблицами на диске).
2. Хорошо настроенная файловая система тоже будет все держать в оперативной памяти и писать на диск при свободных ресурсах на запись, это гораздо лучше и эффективней, чем решать те же проблемы на уровне софта бд.
А в целом при работе с бд надо оптимизировать три кеша: кеш бд, кеш фс, кеш дисковой системы. Если все пихать в кеш бд, то будет эффект двойного кеширования.
2. Хорошо настроенная файловая система тоже будет все держать в оперативной памяти и писать на диск при свободных ресурсах на запись, это гораздо лучше и эффективней, чем решать те же проблемы на уровне софта бд.
А в целом при работе с бд надо оптимизировать три кеша: кеш бд, кеш фс, кеш дисковой системы. Если все пихать в кеш бд, то будет эффект двойного кеширования.
BolgenSQL, шоле?
а в чем отличие от tarantool?
> MemSQL — это база данных следующего поколения...
Ничего принципиально нового не заметил в описании, кроме разве что пафоса
Ничего принципиально нового не заметил в описании, кроме разве что пафоса
Я честно пытался послушать Никиту на DUMP через скайп и в итоге понял только одно memSQL дает очень большие скорости на чтении потому что хранит все в памяти. Опять же кое какие возможности даже MySQL они по выкидывали ради этого. Думается мне ввиду работы Никиты над MS SQL до этого — шансы есть. Но вот бизнес модель сомнительная.
Не могу не удивиться глупости инвесторов:
— выкидывать на рынок решение с закрытым исходным кодом
— нарушать GPL
— основывать архитектуру in-memory database на основе кода MySQL, Которому 15 лет и который *не айс*, как по качеству кода так и по архитектурным решениям.
Я, конечно, человек ангажированный, но всё это похоже на какую-то разводку (с)
— выкидывать на рынок решение с закрытым исходным кодом
— нарушать GPL
— основывать архитектуру in-memory database на основе кода MySQL, Которому 15 лет и который *не айс*, как по качеству кода так и по архитектурным решениям.
Я, конечно, человек ангажированный, но всё это похоже на какую-то разводку (с)
Прочитал маркетинговый опус и не смог ответить на вопрос: а почему ускорение именно в 30, а не, скажем, в 100 раз?
Узкое место серверов баз данных это всегда диски (при крупных объемах информации). Существенного прогресса в ускорении программной части работы с диском сейчас можно добиться, только снизив уровни транзакций. Последствия этого шага могут быть весьма печальны, особенно если это сделано в тихую, без явного информирования конечного пользователя.
Некоторое ускорение может дать собственная файловая система, как это есть у Oracle. Но это ускорение по сравнению с хорошо настроенной файловой системой невелико (даже до двух раз не дотягивает, не говоря уже о 30-и).
Другой вариант это оптимизация работы с кластерами, т.е. создание эффективных алгоритмов аудита и оптимизации данных при кластерной архитектуре. Но кластерные решения обычно узкоспециализированы и поэтому, создание универсального кластерного сервера баз данных, которое даст «ускорение в 30 раз», выглядит сомнительно.
Третий вариант программного ускорения это создание эффективных алгоритмов кеширования. Универсального решения тут нет. Задача кеширования уже имеет и богатую научную историю, и прикладную, и практическую, ничего радикально нового («ускорение в 30 раз») на имеющейся технологической базе здесь появиться не может.
Если этот проект имеет цель добиться «ускорения в 30 раз», а не просто освоить деньги, то возможно, по своей сути, это просто эффективная, абстрагированная от логики mysql, настройка сервера баз данных под несколько конкретных задач. В этом случае, ускорение в 30 раз по сравнению с ненастроенным сервером добиться можно.
Но в этом случае, для хороших специалистов memSQL не даст ничего нового.
Вывод:
Дали $3*10^6 на тему разработки софта ускоряющего работу с диском в 30 раз. Вопрос почему?
Узкое место серверов баз данных это всегда диски (при крупных объемах информации). Существенного прогресса в ускорении программной части работы с диском сейчас можно добиться, только снизив уровни транзакций. Последствия этого шага могут быть весьма печальны, особенно если это сделано в тихую, без явного информирования конечного пользователя.
Некоторое ускорение может дать собственная файловая система, как это есть у Oracle. Но это ускорение по сравнению с хорошо настроенной файловой системой невелико (даже до двух раз не дотягивает, не говоря уже о 30-и).
Другой вариант это оптимизация работы с кластерами, т.е. создание эффективных алгоритмов аудита и оптимизации данных при кластерной архитектуре. Но кластерные решения обычно узкоспециализированы и поэтому, создание универсального кластерного сервера баз данных, которое даст «ускорение в 30 раз», выглядит сомнительно.
Третий вариант программного ускорения это создание эффективных алгоритмов кеширования. Универсального решения тут нет. Задача кеширования уже имеет и богатую научную историю, и прикладную, и практическую, ничего радикально нового («ускорение в 30 раз») на имеющейся технологической базе здесь появиться не может.
Если этот проект имеет цель добиться «ускорения в 30 раз», а не просто освоить деньги, то возможно, по своей сути, это просто эффективная, абстрагированная от логики mysql, настройка сервера баз данных под несколько конкретных задач. В этом случае, ускорение в 30 раз по сравнению с ненастроенным сервером добиться можно.
Но в этом случае, для хороших специалистов memSQL не даст ничего нового.
Вывод:
Дали $3*10^6 на тему разработки софта ускоряющего работу с диском в 30 раз. Вопрос почему?
Какую функцию выполняет вот эта картинка в посте?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MemSQL has launched!