https://www.opennet.dev/openforum/vsluhforumID3/71758.html Доступен перевод (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-as-nosql-story-for.html)" (Использование MySQL как NoSQL &#8212; История о том, как достичь 750,000 запросов в секунду). Компания, в которой работает Yoshinori Matsunobu разработала и успешно использует MySQL-плагин, который позволяет обрабатывать более 750 тысяч запросов в секунду на вполне обычном железе. Решение - очень красивое, при этом позволяет использовать как обычные SQL-запросы, так и достигать производительности, которая не доступна даже NoSQL-продуктам.<br><br><br>Дополнительно можно обратить внимание на статью "Схема базы данных SQL с минимальным количеством таблиц (http://wiki.opennet.ru/%D0%A1%D1%85%D0%B5%D0%BC%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_SQL_%D1%81_%D0%BC%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B...<br><br>URL: http://l-o-n-g https://www.opennet.dev/openforum/vsluhforumID3/71758.html#13 Mon, 25 Oct 2010 21:05:59 GMT Для баз до 100 гигов, а это не такая уж и мелочь для подавляющего большинства более менее серьёзных веб-приложений, не выделять память для базы может только религиозно озабоченный олигофрен или толстосумм. Это не то чтобы повод поспорить, просто опыт. Опять же - с другой стороны? сильноутрамбованные раиды неплохо держат конкуренцию с памятью - при таких объемах, масштаб потерь ничтожен, хоть и сильно упирается в рандом.<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#12 Mon, 25 Oct 2010 19:16:06 GMT &gt; угу. т.к. это работает только для memory only.<br><br>только вот ведь незадача - это попрежнему БД на файлах.<br>Ты статью-то читал? Дикий прирост производительности достигается засчет отказа от парсера SQL-запросов. Который, однако, дает лишь мизерную задержку по сравнению с чтением данных с диска. Поэтому, если БД не полностью в памяти - все это нахер не нужно, ибо боттлнек будет в другом месте.<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#11 Mon, 25 Oct 2010 17:09:27 GMT &gt; История о том, как достичь 750,000 запросов в секунду<br><br>История о том, как достичь 750,000 ответов в секунду, надо бы...<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#10 Mon, 25 Oct 2010 15:11:29 GMT Ну видимо имеется ввиду "бюджетный сервер", а не мощный сервер БД. В реальных задачах под БД может приобретаться очень дорогое железо - x86 с несколькими процессорами (напр. 4 проца и 96 гигов памяти и пара полок дисков - вполне себе обычный сервер под рабочую нагрузку), либо не x86 вообще, что еще дороже. Кто-то до кластеров докатывается, что безумно сложно и так же безумно дорого. Тут же кто-то в ветке про мейнфреймы кто-то доказывал, почему они так хороши под БД, где нужно хорошее масштабирование.<br><br>Этот простенький сервер, в который разве что воткнули сетевушку о четырех интерфейсах и памяти побольше (ну потянет оно тысяч на 5-6 долларов, возможно) - железо уровня типичного современного десктопа по производительности, и в 10-50 раз дешевле многих мощных серверов БД :)<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#9 Mon, 25 Oct 2010 14:49:19 GMT 2.53GHz x8, 32 гига, 3 Гигабита, это вполне обычное железо. А необычное, это что?<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#8 Mon, 25 Oct 2010 11:14:54 GMT Так и есть. От данных, что от них нам нужно -- чтоб они были в виде одного большого куска (блоба), а к нему была приделана куча вторичных индексов. Ну, и чтоб при добавлении/удалении блобов вторичные индексы автоматически обновлялись. А Кодд тихо курит в сторонке. <br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#7 Mon, 25 Oct 2010 10:59:29 GMT &gt; угу. т.к. это работает только для memory only.<br><br>только вот ведь незадача - это попрежнему БД на файлах. Обидно, да? :)<br><br>&gt;не знаю что это за задача такая. Встроенного шардинга <br><br>Доступа - в смысле задержек. Они меньше.<br><br>&gt;какой? на чтение из кеша - решает. На запись и чтение диска - нет. <br><br>в NOSQL запись... там вообще его нет, только временное хранение :) Сейчас допилят постоянное и они станут не быстрее традиционных sql.<br><br>&gt; мм... mysql не самая надежная бд. <br><br>а NoSQL вообще понятие "надёжность" отсутствует. Или непонимай?<br><br>&gt; очень хорошо. (что я и написал)<br><br>подозреваю, что и здесь вы "прочитали" только то, что хотели бы видеть - задержки ниже, чем у редиса (показатель выше) :)<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#6 Mon, 25 Oct 2010 09:28:24 GMT _поэтому_<br> https://www.opennet.dev/openforum/vsluhforumID3/71758.html#5 Mon, 25 Oct 2010 08:13:35 GMT &gt; Каких задач? <br>&gt; Хранения? <br><br>угу. т.к. это работает только для memory only.<br><br>&gt; Доступа? <br><br>не знаю что это за задача такая. Встроенного шардинга вроде нет, а то, что есть для mysql использовать нельзя, т.к. другой апи.<br><br>&gt; Скорости? <br><br>какой? на чтение из кеша - решает. На запись и чтение диска - нет. <br><br>&gt; Надежности? <br><br>мм... mysql не самая надежная бд. <br><br>&gt; Задержки? Все показатели выше, чем<br>&gt; у того же Redis http://code.google.com/p/redis/wiki/Benchmarks<br><br>очень хорошо. (что я и написал)<br><br><br><br><br>