MySQL сможет работать как NoSQL сервер

NoSQL

В экспериментальной версии (5.6.2) Oracle mysql появился плагин, позволяющий обращаться к innodb или ndb (mysql cluster) данным через memcached интерфейс. Оставляя возможность доступа к тем же данным через sql интерфейс.

Описание здесь:
Сообщение Оракла
http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/

Код:
http://labs.mysql.com/

Теги:

Хабы:

NoSQL

Ой, у вас баннер убежал!

Ну. И что?

+38
2,9k
57
Поделиться
- Скопировать ссылку
- Facebook
- Twitter
- ВКонтакте
- Telegram
- Pocket

Odobenus Rosmarus OdobenusRosmarus

Пользователь

15 марта 2010 в 20:43
MongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ

+50 26,3k 55 71
19 июля 2009 в 09:21
Краткий обзор движков таблиц MySQL

+93 63,3k 340 73
9 декабря 2008 в 16:34
Блокировки в MySQL

+59 89,3k 239 18

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

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

НЛО прилетело и опубликовало эту надпись здесь
BarsMonster 13 апреля 2011 в 07:20
0
Интерфейсы это хорошо, но покажет ли он и скорость как NoSQL сервера? Прослойку написать и раньше можно было :-)
- OdobenusRosmarus 13 апреля 2011 в 08:07
  +2
  прослойка это не то, о чем говорится. В случае прослойки сначала парсится nosql протокол, затем он переводится в sql, который опять парсится уже mysql сервером. То есть работы — добавляется. В случае плагина nosql интерфейс используется вместо sql, то есть весь sql слой просто не участвует при разборе запроса.
  
  Что же касается скорости ndb (к примеру) без sql слоя — вот тут есть тесты самого Оракла на этот счет, они получили на кластере из 16 машин 6.8 миллионов чтений в секунду и 2.4 миллиона updates в секунду.
  
  «если правда оно, ну хотя бы на треть» ( (с) Высоцкий), то ожидается заметный прирост производительности при использовании nosql плагина.
  - BarsMonster 13 апреля 2011 в 08:10
    
    0
    Да, тогда это несколько меняет дело. Впрочем, выложил бы кто тесты на нормальном, рабоче-крестьянском железе :-D
    - 80x86 13 апреля 2011 в 09:50
      
      0
      
      Зачем носкуль на рабоче-крестьянском железе-то? :)
      - VolCh 14 апреля 2011 в 02:32
        
        0
        
        Чтобы не покупать оракловское? :)
        
        80x86 14 апреля 2011 в 06:51
        
        0
        
        Так говорил Зар^W^W делал Google!
- akalend 14 апреля 2011 в 03:13
  0
  >но покажет ли он и скорость как NoSQL сервера
  не скажу за этот новый плагин, но HandlerSocket имеет довольно-таки хорощую производительность, соизмеримую с MemcachDb
  Разработчики его на 16 ядерном сервере разогнали до 7500 rps, у меня на слабом на двухядерном получилось лишь 3500, при том что максимальный разгон SQL — около 400.
  - akalend 14 апреля 2011 в 03:16
    
    0
    судя по схеме, HS общается в Хранилищами через HS API
    а этот плагин — напрямую через InnoDb API, которое было включено именно в этот плагин. Так что еще на одну прослойку меньше — скорость должна быть выше.
zizop 13 апреля 2011 в 08:43
+1
Отлично! Можно только порадоваться за MySQL. Интересно, когда теперь Percona обновится до 5.6.2…
- hellohaos 13 апреля 2011 в 13:55
  0
  Хотя бы релиз версии 5,5 сделали
  - zizop 13 апреля 2011 в 14:38
    
    +1
    Так уже сделали же. В репозитариях лежит percona-server-5.5 у них. Недавно обновились.
    - hellohaos 13 апреля 2011 в 16:46
      
      0
      
      Насколько я понимаю у них пока тока RC доступен:
      5.5 RC (5.5.10-20.1)
      www.percona.com/software/percona-server/downloads/
      Или я что-то путаю?
      - zizop 13 апреля 2011 в 19:04
        
        0
        
        Да, всё верно.
        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
DunkanVS 13 апреля 2011 в 09:15
+10
Прикол в том, что InnoDB изначально был key:value базой данных, обернутой в Sql. :)
GearHead 13 апреля 2011 в 09:32
–3
а какой конкретно NoSQL? Если это Key-Value хранилище, то чем это отличается от SELECT FROM something WHERE id = n?
- Mear 13 апреля 2011 в 09:35
  +6
  Как минимум отсутствием затрат времени на парсинг SQL-запроса.
  - GearHead 13 апреля 2011 в 09:53
    
    –3
    а какие-то ещё нововведения есть?
    а то лично для себя я не вижу в этом большого плюса (не считаю, что затраты на парсинг являются значительными по сравнению с самим запросом, и что их отсутствие сильно повысит производительность)
    - 80x86 13 апреля 2011 в 09:59
      
      +8
      
      Это отличный плюс в борьбе с nosql-фанатиками.
      - GearHead 13 апреля 2011 в 10:04
        
        –3
        
        я в некоторой степени могу себя назвать nosql-фанатиком (но с mysql тоже периодически приходится работать), и честно говоря я ещё не нашёл ни одного реального плюса этого нововведения по сравнению с nosql решениями.
        
        zerkms 13 апреля 2011 в 10:33
        
        0
        
        Это позволит выполнить «сложный» запрос из sql.
        Любой запрос из разряда «чтобы получить такое в KV необходимо поддерживать коллекции вручную». Например: N последних (id DESC) сущностей по какому-то критеорию.
        
        80x86 13 апреля 2011 в 10:40
        
        +5
        
        Думаю, не надо говорить, что в основе и релиционных SQL-driven СУБД и различных nosql-СУБД лежат аналогичные принципы хранения и выборки данных. Сейчас MySQL с memcached и прочими достаточно тривиальными навесками вполне сравнима со всякими mongodb, редисами и иными неспециализированными решениями для организации key-value хранилищ.
        
        Но его огромный плюс в том, что с его SQL-фронтэндом имеется возможность при необходимости без костылей прозрачно использовать это key-value хранилище и в обычной реляционной модели взаимодействия.
        
        Ещё скажите, что это не плюс.
        
        80x86 13 апреля 2011 в 12:05
        
        0
        
        Ужас с грамматикой. Реляционных, конечно же.
        
        GearHead 13 апреля 2011 в 13:09
        
        –1
        
        я вам не про минус MySQL говорил, а про минус решения. я не понимаю, в чём возможность выборки строки из таблицы по ID без sql запроса вдруг превращает MySQL в NoSQL.
        
        80x86 13 апреля 2011 в 13:17
        
        0
        
        Вы по оригинальной ссылке ходили?
        
        Там приведена схема архитектуры приложения, которая всё разъясняет. Выше уже было сказано, что оригинальный InnoDB-engine — классическое хранилище key-value.
        
        Надеюсь, с текстом по этой ссылке вы спорить не будете и после вчитывания в типы NoSQL-хранилищ согласитесь с тем, что InnoDB и архитектура, предложенная Oracle — ни что иное, как один из типов NoSQL.
        
        VolCh 14 апреля 2011 в 02:41
        
        0
        
        Используют упрощенную, более гибкую, не ограниченную схемой структуру базы данных;
        
        Вот этот признак NoSQL я как-то не увидел в плагине реализован или нет? Для меня он главный плюс Mongo Couch и т. п.
        
        akalend 14 апреля 2011 в 02:56
        
        0
        
        нет не реализован
        
        80x86 14 апреля 2011 в 07:09
        
        +1
        
        Структура таблиц, к сожалению, статическая, хотя в официальной документации было что-то про динамический формат строк. В ембеддед-версии InnoDB схема точно статическая (насчёт других версий не проверял, но, похоже, кодовая база одна).
        
        И это грустно, конечно.
        
        akalend 14 апреля 2011 в 03:05
        
        0
        
        в статье ясно сказано, что есть разные типы noSQL
        одна из них — key/value
        По этому признаку — InnoDB + memcached_plugin можно считать noSQL
      - lega 13 апреля 2011 в 12:04
        
        0
        
        Я думаю, GearHead имел ввиду что плюс есть, но это не заменит nosql.
    - OdobenusRosmarus 13 апреля 2011 в 10:18
      
      +11
      
      Это зависит от типа запросов. Для сложных запросов или запросов возвращающих много данных (ну грубо говоря OLAP), действительно sql overhead можно пренебречь.
      
      Для частых однотипных запросов типа select * from table where pkey=число, (грубо говоря OLTP) которые выполянются «много тыщщ» раз в секунду, также много тыщщ раз в секунду выполняется лексический анализ запроса, парсинг, обращение к схеме (чтобы узнать поля и индексы), query cache, оптимизатор и т.д. И в этом случае overhead уже очень заметен.
      
      Откуда по Вашему появилось вообще движение NoSQL? — это борьба с overskills обычных sql серверов.
      
      В случае нового плагина появляется уникальная возможность комбинации подходов — использовать nosql там где нужно, и sql там где можно.
      - syber 14 апреля 2011 в 03:42
        
        +1
        
        «Для частых однотипных запросов типа select * from table where pkey=число, (грубо говоря OLTP) которые выполянются «много тыщщ» раз в секунду, также много тыщщ раз в секунду выполняется лексический анализ запроса, парсинг, обращение к схеме (чтобы узнать поля и индексы), query cache, оптимизатор и т.д. И в этом случае overhead уже очень заметен.»
        
        Не совсем так, если использовать persistent connection и подготоваливать запросы (prepare cached), то план запроса, план отпимизации итд выполняется всего 1 раз, а затем запрос выполняется очень быстро, почти без overheat на то, что вы перечислили.
        
        akalend 14 апреля 2011 в 10:10
        
        0
        
        производительность HS в сотни раз выше, даже при persisten connection
        чем обращение через SQL API
        делал тесты. Если интересно то приглашаю на AddConf addconf.ru послушать доклад про HandlerSocket
        Есть промокод на 5% скидку «Имя-Фамилия-докладчика — читаю» («Александр Календарев — читаю»).
- soines 13 апреля 2011 в 09:39
  0
  Ну как минимум тем, что не происходит парсинг и разбор sql запроса.
  - kirilloid 13 апреля 2011 в 18:26
    
    0
    У меня есть подозрение, что парсинг и запроса отрабатывает гораздо быстрей, чем затраты на соединение и прочие оверхеды.
    Хотя, например, pconnect нивелирует затраты на соединение.
shitware 13 апреля 2011 в 14:42
–4
если к велику приварить вторую раму и второе седло то можно кататься вдоем
phasma 13 апреля 2011 в 15:07
+1
А тесты в сравнении с handlersocket уже есть?

И как с правами? Можно как-то ограничить доступ?
- akalend 14 апреля 2011 в 03:19
  0
  там есть таблицы, типа PERFOMENCE_SCHEMA
  через которые можно рулить этим великом…
akalend 13 апреля 2011 в 19:12
0
еще бы кто протестировал на сколько это быстрее HS
akalend 13 апреля 2011 в 19:12
0
думаю опять мне придется тестировать :)
- akalend 13 апреля 2011 в 19:18
  –1
  судя по описанию, оно должно работать быстрее
  MC — обращение к InnoDb напрямую через InnoDbAPI
  HS — через HS API, который лежит над InnoDbAPI
  
  1) сам Протокол HS на мой взгляд гибче…
  2) скоро введется лицензионная плата на использование innoDb,
  так что переходим на Перкону. У нас руководство вообще хочет проект на Постгресс пересадить
  - phasma 13 апреля 2011 в 19:22
    
    0
    > 2) скоро введется лицензионная плата на использование innoDb,
    
    есть достоверный источник?
    - akalend 13 апреля 2011 в 21:41
      
      0
      
      точной даты нет, но на сайте Оракла было сообщение что они собираются это сделать в течении 6-ти мес
      - OdobenusRosmarus 13 апреля 2011 в 22:48
        
        0
        
        я довольно тщательно слежу за новостями про иннодб, но не видел ни разу такой новости. Ссылкой не поделитесь?
        
        И — не обижайтесь — но выглядит такая новость не очень правдоподобно.
        
        akalend 14 апреля 2011 в 01:59
        
        0
        
        согл, слухи…
        по этому и не поделюсь
  - syber 13 апреля 2011 в 22:59
    
    0
    На самом деле пересадить на postgres мысль с одной стороны хорошая с другой плохая. Постгря — более мощная по возможностям база чем mysql, да и имеет ряд преимуществ при поддержке больших таблиц, например не блокирующееся постоение индексов, неблокирующееся изменение структуры таблицы итд. Однако постгря это сложная БД и чтобы правильно ее настроить и использовать, требуется опыт работы с ней. Так что решение весьма спорное )) Но если опыт с постгрей есть, то я бы сказал что это более предпочтительная БД для больших проектов, чем MySQL.
    - BigD 13 апреля 2011 в 23:53
      
      0
      
      но NoSQL там не сделаешь?
      - akalend 14 апреля 2011 в 01:54
        
        0
        
        почему??
      - akalend 14 апреля 2011 в 02:55
        
        0
        
        изучаешь www.postgresql.org/docs/9.0/static/protocol.html
        и пишешь свой nosql подход
        по времени займет месяц-два.
      - 80x86 14 апреля 2011 в 07:12
        
        0
        
        Носкуль делается из любой РБД. Вопрос только в кучах абстракций :)
akalend 13 апреля 2011 в 22:30
0
как это дело устанавливать
blogs.innodb.com/wp/2011/04/get-started-with-innodb-memcached-daemon-plugin/
akalend 14 апреля 2011 в 01:53
0
я конечно верю ребярам из Оракла, что они соорудили крутую штуку
но не работает ни чего:
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
и уже больше не поднимается…
- akalend 14 апреля 2011 в 02:02
  0
  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
- stab 31 августа 2011 в 12:38
  0
  А нам удалось под FreeBSD собрать и даже немного поиграться, скорость ещё не тестировали, огорчает что expire time пока (?) не поддерживается или мы что-то не так делаем.
  - akalend 31 августа 2011 в 17:53
    
    0
    спасибо за информацию,
    может новый билд соберется.
Vertex 15 апреля 2011 в 21:17
0
А меня лично просто радуют вообще любые слухи и информация, о том что Oracle не «забила» на MySQL, а все-таки хоть как-то ее развивает и поддерживает.
- akalend 31 августа 2011 в 17:52
  0
  да. согласен
  об Оракле есть такая слава: купить и загубить — это синонимы…
  надеюсь — это со временем опровергнется