Pull to refresh

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 плагина.
Да, тогда это несколько меняет дело. Впрочем, выложил бы кто тесты на нормальном, рабоче-крестьянском железе :-D
Зачем носкуль на рабоче-крестьянском железе-то? :)
Чтобы не покупать оракловское? :)
Так говорил Зар^W^W делал Google!
>но покажет ли он и скорость как NoSQL сервера
не скажу за этот новый плагин, но HandlerSocket имеет довольно-таки хорощую производительность, соизмеримую с MemcachDb
Разработчики его на 16 ядерном сервере разогнали до 7500 rps, у меня на слабом на двухядерном получилось лишь 3500, при том что максимальный разгон SQL — около 400.
судя по схеме, HS общается в Хранилищами через HS API
а этот плагин — напрямую через InnoDb API, которое было включено именно в этот плагин. Так что еще на одну прослойку меньше — скорость должна быть выше.
Отлично! Можно только порадоваться за MySQL. Интересно, когда теперь Percona обновится до 5.6.2…
Хотя бы релиз версии 5,5 сделали
Так уже сделали же. В репозитариях лежит percona-server-5.5 у них. Недавно обновились.
Прикол в том, что InnoDB изначально был key:value базой данных, обернутой в Sql. :)
а какой конкретно NoSQL? Если это Key-Value хранилище, то чем это отличается от SELECT FROM something WHERE id = n?
Как минимум отсутствием затрат времени на парсинг SQL-запроса.
а какие-то ещё нововведения есть?
а то лично для себя я не вижу в этом большого плюса (не считаю, что затраты на парсинг являются значительными по сравнению с самим запросом, и что их отсутствие сильно повысит производительность)
Это отличный плюс в борьбе с nosql-фанатиками.
я в некоторой степени могу себя назвать nosql-фанатиком (но с mysql тоже периодически приходится работать), и честно говоря я ещё не нашёл ни одного реального плюса этого нововведения по сравнению с nosql решениями.
Это позволит выполнить «сложный» запрос из sql.
Любой запрос из разряда «чтобы получить такое в KV необходимо поддерживать коллекции вручную». Например: N последних (id DESC) сущностей по какому-то критеорию.
Думаю, не надо говорить, что в основе и релиционных SQL-driven СУБД и различных nosql-СУБД лежат аналогичные принципы хранения и выборки данных. Сейчас MySQL с memcached и прочими достаточно тривиальными навесками вполне сравнима со всякими mongodb, редисами и иными неспециализированными решениями для организации key-value хранилищ.

Но его огромный плюс в том, что с его SQL-фронтэндом имеется возможность при необходимости без костылей прозрачно использовать это key-value хранилище и в обычной реляционной модели взаимодействия.

Ещё скажите, что это не плюс.
Ужас с грамматикой. Реляционных, конечно же.
я вам не про минус MySQL говорил, а про минус решения. я не понимаю, в чём возможность выборки строки из таблицы по ID без sql запроса вдруг превращает MySQL в NoSQL.
Вы по оригинальной ссылке ходили?

Там приведена схема архитектуры приложения, которая всё разъясняет. Выше уже было сказано, что оригинальный InnoDB-engine — классическое хранилище key-value.

Надеюсь, с текстом по этой ссылке вы спорить не будете и после вчитывания в типы NoSQL-хранилищ согласитесь с тем, что InnoDB и архитектура, предложенная Oracle — ни что иное, как один из типов NoSQL.
Используют упрощенную, более гибкую, не ограниченную схемой структуру базы данных;

Вот этот признак NoSQL я как-то не увидел в плагине реализован или нет? Для меня он главный плюс Mongo Couch и т. п.
Структура таблиц, к сожалению, статическая, хотя в официальной документации было что-то про динамический формат строк. В ембеддед-версии InnoDB схема точно статическая (насчёт других версий не проверял, но, похоже, кодовая база одна).

И это грустно, конечно.
в статье ясно сказано, что есть разные типы 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 уже очень заметен.»

Не совсем так, если использовать persistent connection и подготоваливать запросы (prepare cached), то план запроса, план отпимизации итд выполняется всего 1 раз, а затем запрос выполняется очень быстро, почти без overheat на то, что вы перечислили.
производительность HS в сотни раз выше, даже при persisten connection
чем обращение через SQL API
делал тесты. Если интересно то приглашаю на AddConf addconf.ru послушать доклад про HandlerSocket
Есть промокод на 5% скидку «Имя-Фамилия-докладчика — читаю» («Александр Календарев — читаю»).
Ну как минимум тем, что не происходит парсинг и разбор sql запроса.
У меня есть подозрение, что парсинг и запроса отрабатывает гораздо быстрей, чем затраты на соединение и прочие оверхеды.
Хотя, например, pconnect нивелирует затраты на соединение.
если к велику приварить вторую раму и второе седло то можно кататься вдоем
А тесты в сравнении с handlersocket уже есть?

И как с правами? Можно как-то ограничить доступ?
там есть таблицы, типа PERFOMENCE_SCHEMA
через которые можно рулить этим великом…
еще бы кто протестировал на сколько это быстрее HS
думаю опять мне придется тестировать :)
судя по описанию, оно должно работать быстрее
MC — обращение к InnoDb напрямую через InnoDbAPI
HS — через HS API, который лежит над InnoDbAPI

1) сам Протокол HS на мой взгляд гибче…
2) скоро введется лицензионная плата на использование innoDb,
так что переходим на Перкону. У нас руководство вообще хочет проект на Постгресс пересадить
> 2) скоро введется лицензионная плата на использование innoDb,

есть достоверный источник?
точной даты нет, но на сайте Оракла было сообщение что они собираются это сделать в течении 6-ти мес
я довольно тщательно слежу за новостями про иннодб, но не видел ни разу такой новости. Ссылкой не поделитесь?

И — не обижайтесь — но выглядит такая новость не очень правдоподобно.
согл, слухи…
по этому и не поделюсь
На самом деле пересадить на postgres мысль с одной стороны хорошая с другой плохая. Постгря — более мощная по возможностям база чем mysql, да и имеет ряд преимуществ при поддержке больших таблиц, например не блокирующееся постоение индексов, неблокирующееся изменение структуры таблицы итд. Однако постгря это сложная БД и чтобы правильно ее настроить и использовать, требуется опыт работы с ней. Так что решение весьма спорное )) Но если опыт с постгрей есть, то я бы сказал что это более предпочтительная БД для больших проектов, чем MySQL.
но NoSQL там не сделаешь?
Носкуль делается из любой РБД. Вопрос только в кучах абстракций :)
я конечно верю ребярам из Оракла, что они соорудили крутую штуку
но не работает ни чего:
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, а все-таки хоть как-то ее развивает и поддерживает.
да. согласен
об Оракле есть такая слава: купить и загубить — это синонимы…
надеюсь — это со временем опровергнется
Only those users with full accounts are able to leave comments. Log in, please.