Comments 57
UFO just landed and posted this here
Интерфейсы это хорошо, но покажет ли он и скорость как NoSQL сервера? Прослойку написать и раньше можно было :-)
прослойка это не то, о чем говорится. В случае прослойки сначала парсится nosql протокол, затем он переводится в sql, который опять парсится уже mysql сервером. То есть работы — добавляется. В случае плагина nosql интерфейс используется вместо sql, то есть весь sql слой просто не участвует при разборе запроса.
Что же касается скорости ndb (к примеру) без sql слоя — вот тут есть тесты самого Оракла на этот счет, они получили на кластере из 16 машин 6.8 миллионов чтений в секунду и 2.4 миллиона updates в секунду.
«если правда оно, ну хотя бы на треть» ( (с) Высоцкий), то ожидается заметный прирост производительности при использовании nosql плагина.
Что же касается скорости ndb (к примеру) без sql слоя — вот тут есть тесты самого Оракла на этот счет, они получили на кластере из 16 машин 6.8 миллионов чтений в секунду и 2.4 миллиона updates в секунду.
«если правда оно, ну хотя бы на треть» ( (с) Высоцкий), то ожидается заметный прирост производительности при использовании nosql плагина.
>но покажет ли он и скорость как NoSQL сервера
не скажу за этот новый плагин, но HandlerSocket имеет довольно-таки хорощую производительность, соизмеримую с MemcachDb
Разработчики его на 16 ядерном сервере разогнали до 7500 rps, у меня на слабом на двухядерном получилось лишь 3500, при том что максимальный разгон SQL — около 400.
не скажу за этот новый плагин, но HandlerSocket имеет довольно-таки хорощую производительность, соизмеримую с MemcachDb
Разработчики его на 16 ядерном сервере разогнали до 7500 rps, у меня на слабом на двухядерном получилось лишь 3500, при том что максимальный разгон SQL — около 400.
Отлично! Можно только порадоваться за MySQL. Интересно, когда теперь Percona обновится до 5.6.2…
Хотя бы релиз версии 5,5 сделали
Так уже сделали же. В репозитариях лежит percona-server-5.5 у них. Недавно обновились.
Насколько я понимаю у них пока тока RC доступен:
5.5 RC (5.5.10-20.1)
www.percona.com/software/percona-server/downloads/
Или я что-то путаю?
5.5 RC (5.5.10-20.1)
www.percona.com/software/percona-server/downloads/
Или я что-то путаю?
Да, всё верно.
repo.percona.com/apt-rc/dists/maverick/main/binary-amd64/Packages
Package: percona-server-server
Source: percona-server-5.5
Version: 5.5.10-rc20.1-104.maverick
repo.percona.com/apt-rc/dists/maverick/main/binary-amd64/Packages
Package: percona-server-server
Source: percona-server-5.5
Version: 5.5.10-rc20.1-104.maverick
Прикол в том, что InnoDB изначально был key:value базой данных, обернутой в Sql. :)
а какой конкретно NoSQL? Если это Key-Value хранилище, то чем это отличается от SELECT FROM something WHERE id = n?
Как минимум отсутствием затрат времени на парсинг SQL-запроса.
а какие-то ещё нововведения есть?
а то лично для себя я не вижу в этом большого плюса (не считаю, что затраты на парсинг являются значительными по сравнению с самим запросом, и что их отсутствие сильно повысит производительность)
а то лично для себя я не вижу в этом большого плюса (не считаю, что затраты на парсинг являются значительными по сравнению с самим запросом, и что их отсутствие сильно повысит производительность)
Это отличный плюс в борьбе с nosql-фанатиками.
я в некоторой степени могу себя назвать nosql-фанатиком (но с mysql тоже периодически приходится работать), и честно говоря я ещё не нашёл ни одного реального плюса этого нововведения по сравнению с nosql решениями.
Это позволит выполнить «сложный» запрос из sql.
Любой запрос из разряда «чтобы получить такое в KV необходимо поддерживать коллекции вручную». Например: N последних (id DESC) сущностей по какому-то критеорию.
Любой запрос из разряда «чтобы получить такое в KV необходимо поддерживать коллекции вручную». Например: N последних (id DESC) сущностей по какому-то критеорию.
Думаю, не надо говорить, что в основе и релиционных SQL-driven СУБД и различных nosql-СУБД лежат аналогичные принципы хранения и выборки данных. Сейчас MySQL с memcached и прочими достаточно тривиальными навесками вполне сравнима со всякими mongodb, редисами и иными неспециализированными решениями для организации key-value хранилищ.
Но его огромный плюс в том, что с его SQL-фронтэндом имеется возможность при необходимости без костылей прозрачно использовать это key-value хранилище и в обычной реляционной модели взаимодействия.
Ещё скажите, что это не плюс.
Но его огромный плюс в том, что с его SQL-фронтэндом имеется возможность при необходимости без костылей прозрачно использовать это key-value хранилище и в обычной реляционной модели взаимодействия.
Ещё скажите, что это не плюс.
Ужас с грамматикой. Реляционных, конечно же.
я вам не про минус MySQL говорил, а про минус решения. я не понимаю, в чём возможность выборки строки из таблицы по ID без sql запроса вдруг превращает MySQL в NoSQL.
Вы по оригинальной ссылке ходили?
Там приведена схема архитектуры приложения, которая всё разъясняет. Выше уже было сказано, что оригинальный InnoDB-engine — классическое хранилище key-value.
Надеюсь, с текстом по этой ссылке вы спорить не будете и после вчитывания в типы NoSQL-хранилищ согласитесь с тем, что InnoDB и архитектура, предложенная Oracle — ни что иное, как один из типов NoSQL.
Там приведена схема архитектуры приложения, которая всё разъясняет. Выше уже было сказано, что оригинальный InnoDB-engine — классическое хранилище key-value.
Надеюсь, с текстом по этой ссылке вы спорить не будете и после вчитывания в типы NoSQL-хранилищ согласитесь с тем, что InnoDB и архитектура, предложенная Oracle — ни что иное, как один из типов NoSQL.
Используют упрощенную, более гибкую, не ограниченную схемой структуру базы данных;
Вот этот признак NoSQL я как-то не увидел в плагине реализован или нет? Для меня он главный плюс Mongo Couch и т. п.
в статье ясно сказано, что есть разные типы noSQL
одна из них — key/value
По этому признаку — InnoDB + memcached_plugin можно считать noSQL
одна из них — key/value
По этому признаку — InnoDB + memcached_plugin можно считать noSQL
Я думаю, GearHead имел ввиду что плюс есть, но это не заменит nosql.
Это зависит от типа запросов. Для сложных запросов или запросов возвращающих много данных (ну грубо говоря OLAP), действительно sql overhead можно пренебречь.
Для частых однотипных запросов типа select * from table where pkey=число, (грубо говоря OLTP) которые выполянются «много тыщщ» раз в секунду, также много тыщщ раз в секунду выполняется лексический анализ запроса, парсинг, обращение к схеме (чтобы узнать поля и индексы), query cache, оптимизатор и т.д. И в этом случае overhead уже очень заметен.
Откуда по Вашему появилось вообще движение NoSQL? — это борьба с overskills обычных sql серверов.
В случае нового плагина появляется уникальная возможность комбинации подходов — использовать nosql там где нужно, и sql там где можно.
Для частых однотипных запросов типа select * from table where pkey=число, (грубо говоря OLTP) которые выполянются «много тыщщ» раз в секунду, также много тыщщ раз в секунду выполняется лексический анализ запроса, парсинг, обращение к схеме (чтобы узнать поля и индексы), query cache, оптимизатор и т.д. И в этом случае overhead уже очень заметен.
Откуда по Вашему появилось вообще движение NoSQL? — это борьба с overskills обычных sql серверов.
В случае нового плагина появляется уникальная возможность комбинации подходов — использовать nosql там где нужно, и sql там где можно.
«Для частых однотипных запросов типа select * from table where pkey=число, (грубо говоря OLTP) которые выполянются «много тыщщ» раз в секунду, также много тыщщ раз в секунду выполняется лексический анализ запроса, парсинг, обращение к схеме (чтобы узнать поля и индексы), query cache, оптимизатор и т.д. И в этом случае overhead уже очень заметен.»
Не совсем так, если использовать persistent connection и подготоваливать запросы (prepare cached), то план запроса, план отпимизации итд выполняется всего 1 раз, а затем запрос выполняется очень быстро, почти без overheat на то, что вы перечислили.
Не совсем так, если использовать persistent connection и подготоваливать запросы (prepare cached), то план запроса, план отпимизации итд выполняется всего 1 раз, а затем запрос выполняется очень быстро, почти без overheat на то, что вы перечислили.
производительность HS в сотни раз выше, даже при persisten connection
чем обращение через SQL API
делал тесты. Если интересно то приглашаю на AddConf addconf.ru послушать доклад про HandlerSocket
Есть промокод на 5% скидку «Имя-Фамилия-докладчика — читаю» («Александр Календарев — читаю»).
чем обращение через SQL API
делал тесты. Если интересно то приглашаю на AddConf addconf.ru послушать доклад про HandlerSocket
Есть промокод на 5% скидку «Имя-Фамилия-докладчика — читаю» («Александр Календарев — читаю»).
Ну как минимум тем, что не происходит парсинг и разбор sql запроса.
если к велику приварить вторую раму и второе седло то можно кататься вдоем
А тесты в сравнении с handlersocket уже есть?
И как с правами? Можно как-то ограничить доступ?
И как с правами? Можно как-то ограничить доступ?
еще бы кто протестировал на сколько это быстрее HS
думаю опять мне придется тестировать :)
судя по описанию, оно должно работать быстрее
MC — обращение к InnoDb напрямую через InnoDbAPI
HS — через HS API, который лежит над InnoDbAPI
1) сам Протокол HS на мой взгляд гибче…
2) скоро введется лицензионная плата на использование innoDb,
так что переходим на Перкону. У нас руководство вообще хочет проект на Постгресс пересадить
MC — обращение к InnoDb напрямую через InnoDbAPI
HS — через HS API, который лежит над InnoDbAPI
1) сам Протокол HS на мой взгляд гибче…
2) скоро введется лицензионная плата на использование innoDb,
так что переходим на Перкону. У нас руководство вообще хочет проект на Постгресс пересадить
> 2) скоро введется лицензионная плата на использование innoDb,
есть достоверный источник?
есть достоверный источник?
На самом деле пересадить на postgres мысль с одной стороны хорошая с другой плохая. Постгря — более мощная по возможностям база чем mysql, да и имеет ряд преимуществ при поддержке больших таблиц, например не блокирующееся постоение индексов, неблокирующееся изменение структуры таблицы итд. Однако постгря это сложная БД и чтобы правильно ее настроить и использовать, требуется опыт работы с ней. Так что решение весьма спорное )) Но если опыт с постгрей есть, то я бы сказал что это более предпочтительная БД для больших проектов, чем MySQL.
но NoSQL там не сделаешь?
почему??
изучаешь www.postgresql.org/docs/9.0/static/protocol.html
и пишешь свой nosql подход
по времени займет месяц-два.
и пишешь свой nosql подход
по времени займет месяц-два.
Носкуль делается из любой РБД. Вопрос только в кучах абстракций :)
как это дело устанавливать
blogs.innodb.com/wp/2011/04/get-started-with-innodb-memcached-daemon-plugin/
blogs.innodb.com/wp/2011/04/get-started-with-innodb-memcached-daemon-plugin/
я конечно верю ребярам из Оракла, что они соорудили крутую штуку
но не работает ни чего:
1) HS невозможно скомпилить под 5.2
2) после инсталляции daemon_memcached все падает:
но не работает ни чего:
1) HS невозможно скомпилить под 5.2
2) после инсталляции daemon_memcached все падает:
mysql> install plugin daemon_memcached soname «libmemcached.so»;и уже больше не поднимается…
Query OK, 0 rows affected (0,00 sec)
mysql> 110414 01:46:32 mysqld_safe mysqld restarted
110414 01:46:32 mysqld_safe mysqld from pid file /usr/local/mysql/data/akalend.local.pid ended
errorlog
/usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.2-labs-innodb-memcached-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
110414 1:46:32 — mysqld got signal 10;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
А нам удалось под FreeBSD собрать и даже немного поиграться, скорость ещё не тестировали, огорчает что expire time пока (?) не поддерживается или мы что-то не так делаем.
А меня лично просто радуют вообще любые слухи и информация, о том что Oracle не «забила» на MySQL, а все-таки хоть как-то ее развивает и поддерживает.
Sign up to leave a comment.
MySQL сможет работать как NoSQL сервер