| 1.1, Аноним (-), 11:22, 25/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Интересно, правда не решает всех задач 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.
------
| | |
| |
| |
| 3.5, Аноним (-), 12:13, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Каких задач?
> Хранения?
угу. т.к. это работает только для memory only.
> Доступа?
не знаю что это за задача такая. Встроенного шардинга вроде нет, а то, что есть для mysql использовать нельзя, т.к. другой апи.
> Скорости?
какой? на чтение из кеша - решает. На запись и чтение диска - нет.
> Надежности?
мм... mysql не самая надежная бд.
> Задержки? Все показатели выше, чем
> у того же Redis http://code.google.com/p/redis/wiki/Benchmarks
очень хорошо. (что я и написал)
| | |
| |
| 4.7, pro100master (ok), 14:59, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > угу. т.к. это работает только для memory only.
только вот ведь незадача - это попрежнему БД на файлах. Обидно, да? :)
>не знаю что это за задача такая. Встроенного шардинга
Доступа - в смысле задержек. Они меньше.
>какой? на чтение из кеша - решает. На запись и чтение диска - нет.
в NOSQL запись... там вообще его нет, только временное хранение :) Сейчас допилят постоянное и они станут не быстрее традиционных sql.
> мм... mysql не самая надежная бд.
а NoSQL вообще понятие "надёжность" отсутствует. Или непонимай?
> очень хорошо. (что я и написал)
подозреваю, что и здесь вы "прочитали" только то, что хотели бы видеть - задержки ниже, чем у редиса (показатель выше) :)
| | |
| |
| 5.12, Knuckles (ok), 23:16, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > угу. т.к. это работает только для memory only.
только вот ведь незадача - это попрежнему БД на файлах.
Ты статью-то читал? Дикий прирост производительности достигается засчет отказа от парсера SQL-запросов. Который, однако, дает лишь мизерную задержку по сравнению с чтением данных с диска. Поэтому, если БД не полностью в памяти - все это нахер не нужно, ибо боттлнек будет в другом месте.
| | |
| |
| 6.13, pro100master (ok), 01:05, 26/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Для баз до 100 гигов, а это не такая уж и мелочь для подавляющего большинства более менее серьёзных веб-приложений, не выделять память для базы может только религиозно озабоченный олигофрен или толстосумм. Это не то чтобы повод поспорить, просто опыт. Опять же - с другой стороны? сильноутрамбованные раиды неплохо держат конкуренцию с памятью - при таких объемах, масштаб потерь ничтожен, хоть и сильно упирается в рандом.
| | |
|
|
|
|
| 2.3, alz (??), 11:51, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
И какие же это задачи? Термин NoSQL собирательный. И базами данных ключ-значение, хранящимися в оперативной памяти, он не исчерпывается. А название такое, чтобы подчеркнуть, что существуют другие способы хранения и обработки данных, для некоторых задач более подходящие, чем реляционные базы данных
| | |
| |
| 3.4, Аноним (-), 12:01, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Термин NoSQL собирательный.
Конечно. По этому и написал "не все". Ибо статья должны быть названа заменим memcached на rpc к mysql.
А так. Еще вопросы, которые не решает "это":
lucene. (spinx нашлепка и по сути тот же lucene)
bigtable. (большой объем и кластеризация)
cassandra. скорость записи
| | |
| 3.8, Аноним (-), 15:14, 25/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Так и есть. От данных, что от них нам нужно -- чтоб они были в виде одного большого куска (блоба), а к нему была приделана куча вторичных индексов. Ну, и чтоб при добавлении/удалении блобов вторичные индексы автоматически обновлялись. А Кодд тихо курит в сторонке.
| | |
|
|
| 1.9, Ананимуз (?), 18:49, 25/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
2.53GHz x8, 32 гига, 3 Гигабита, это вполне обычное железо. А необычное, это что?
| | |
| |
| 2.10, Stax (ok), 19:11, 25/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Ну видимо имеется ввиду "бюджетный сервер", а не мощный сервер БД. В реальных задачах под БД может приобретаться очень дорогое железо - x86 с несколькими процессорами (напр. 4 проца и 96 гигов памяти и пара полок дисков - вполне себе обычный сервер под рабочую нагрузку), либо не x86 вообще, что еще дороже. Кто-то до кластеров докатывается, что безумно сложно и так же безумно дорого. Тут же кто-то в ветке про мейнфреймы кто-то доказывал, почему они так хороши под БД, где нужно хорошее масштабирование.
Этот простенький сервер, в который разве что воткнули сетевушку о четырех интерфейсах и памяти побольше (ну потянет оно тысяч на 5-6 долларов, возможно) - железо уровня типичного современного десктопа по производительности, и в 10-50 раз дешевле многих мощных серверов БД :)
| | |
|
| 1.11, pavlinux (ok), 21:09, 25/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 > История о том, как достичь 750,000 запросов в секунду
История о том, как достичь 750,000 ответов в секунду, надо бы...
| | |
|
