Доступен перевод (http://l-o-n-g.livejournal.com/153756.html) статьи Yoshinori Matsunobu "Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server (http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-a...)" (Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду). Компания, в которой работает Yoshinori Matsunobu разработала и успешно использует MySQL-плагин, который позволяет обрабатывать более 750 тысяч запросов в секунду на вполне обычном железе. Решение - очень красивое, при этом позволяет использовать как обычные SQL-запросы, так и достигать производительности, которая не доступна даже NoSQL-продуктам.
Дополнительно можно обратить внимание на статью "Схема базы данных SQL с минимальным количеством таблиц (http://wiki.opennet.ru/%D0%A1%D1%85%......URL: http://l-o-n-g.livejournal.com/153756.html
Новость: http://www.opennet.me/opennews/art.shtml?num=28401
Интересно, правда не решает всех задач NoSQL.For HDD i/o bound workloads, a database instance can not execute thousands of queries per second, which normally results in only 1-10% CPU usage. In such cases, SQL execution layer does not become bottleneck, so there is no benefit to use Hanldersocket.
-----
We use HandlerSocket on servers that almost all data fit in memory.
------
Каких задач? Хранения? Доступа? Скорости? Надежности? Задержки? Все показатели выше, чем у того же Redis http://code.google.com/p/redis/wiki/BenchmarksЕсли появятся интерфесы к Python и PHP, то одобрям
> Каких задач?
> Хранения?угу. т.к. это работает только для memory only.
> Доступа?
не знаю что это за задача такая. Встроенного шардинга вроде нет, а то, что есть для mysql использовать нельзя, т.к. другой апи.
> Скорости?
какой? на чтение из кеша - решает. На запись и чтение диска - нет.
> Надежности?
мм... mysql не самая надежная бд.
> Задержки? Все показатели выше, чем
> у того же Redis http://code.google.com/p/redis/wiki/Benchmarksочень хорошо. (что я и написал)
> угу. т.к. это работает только для memory only.только вот ведь незадача - это попрежнему БД на файлах. Обидно, да? :)
>не знаю что это за задача такая. Встроенного шардинга
Доступа - в смысле задержек. Они меньше.
>какой? на чтение из кеша - решает. На запись и чтение диска - нет.
в NOSQL запись... там вообще его нет, только временное хранение :) Сейчас допилят постоянное и они станут не быстрее традиционных sql.
> мм... mysql не самая надежная бд.
а NoSQL вообще понятие "надёжность" отсутствует. Или непонимай?
> очень хорошо. (что я и написал)
подозреваю, что и здесь вы "прочитали" только то, что хотели бы видеть - задержки ниже, чем у редиса (показатель выше) :)
> угу. т.к. это работает только для memory only.только вот ведь незадача - это попрежнему БД на файлах.
Ты статью-то читал? Дикий прирост производительности достигается засчет отказа от парсера SQL-запросов. Который, однако, дает лишь мизерную задержку по сравнению с чтением данных с диска. Поэтому, если БД не полностью в памяти - все это нахер не нужно, ибо боттлнек будет в другом месте.
Для баз до 100 гигов, а это не такая уж и мелочь для подавляющего большинства более менее серьёзных веб-приложений, не выделять память для базы может только религиозно озабоченный олигофрен или толстосумм. Это не то чтобы повод поспорить, просто опыт. Опять же - с другой стороны? сильноутрамбованные раиды неплохо держат конкуренцию с памятью - при таких объемах, масштаб потерь ничтожен, хоть и сильно упирается в рандом.
И какие же это задачи? Термин NoSQL собирательный. И базами данных ключ-значение, хранящимися в оперативной памяти, он не исчерпывается. А название такое, чтобы подчеркнуть, что существуют другие способы хранения и обработки данных, для некоторых задач более подходящие, чем реляционные базы данных
> Термин NoSQL собирательный.Конечно. По этому и написал "не все". Ибо статья должны быть названа заменим memcached на rpc к mysql.
А так. Еще вопросы, которые не решает "это":
lucene. (spinx нашлепка и по сути тот же lucene)
bigtable. (большой объем и кластеризация)
cassandra. скорость записи
_поэтому_
Так и есть. От данных, что от них нам нужно -- чтоб они были в виде одного большого куска (блоба), а к нему была приделана куча вторичных индексов. Ну, и чтоб при добавлении/удалении блобов вторичные индексы автоматически обновлялись. А Кодд тихо курит в сторонке.
2.53GHz x8, 32 гига, 3 Гигабита, это вполне обычное железо. А необычное, это что?
Ну видимо имеется ввиду "бюджетный сервер", а не мощный сервер БД. В реальных задачах под БД может приобретаться очень дорогое железо - x86 с несколькими процессорами (напр. 4 проца и 96 гигов памяти и пара полок дисков - вполне себе обычный сервер под рабочую нагрузку), либо не x86 вообще, что еще дороже. Кто-то до кластеров докатывается, что безумно сложно и так же безумно дорого. Тут же кто-то в ветке про мейнфреймы кто-то доказывал, почему они так хороши под БД, где нужно хорошее масштабирование.Этот простенький сервер, в который разве что воткнули сетевушку о четырех интерфейсах и памяти побольше (ну потянет оно тысяч на 5-6 долларов, возможно) - железо уровня типичного современного десктопа по производительности, и в 10-50 раз дешевле многих мощных серверов БД :)
> История о том, как достичь 750,000 запросов в секундуИстория о том, как достичь 750,000 ответов в секунду, надо бы...