форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

Сообщения по теме

[Сортировка по ответам | RSS]

	1. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Аноним (??) on 25-Окт-10, 11:22
	Интересно, правда не решает всех задач 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. ------
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+1 +/–
	Сообщение от pro100master (ok) on 25-Окт-10, 11:40
	Каких задач? Хранения? Доступа? Скорости? Надежности? Задержки? Все показатели выше, чем у того же Redis http://code.google.com/p/redis/wiki/Benchmarks Если появятся интерфесы к Python и PHP, то одобрям
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от alz (??) on 25-Окт-10, 11:51
	И какие же это задачи? Термин NoSQL собирательный. И базами данных ключ-значение, хранящимися в оперативной памяти, он не исчерпывается. А название такое, чтобы подчеркнуть, что существуют другие способы хранения и обработки данных, для некоторых задач более подходящие, чем реляционные базы данных
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Аноним (??) on 25-Окт-10, 12:01
	> Термин NoSQL собирательный. Конечно. По этому и написал "не все". Ибо статья должны быть названа заменим memcached на rpc к mysql. А так. Еще вопросы, которые не решает "это": lucene. (spinx нашлепка и по сути тот же lucene) bigtable. (большой объем и кластеризация) cassandra. скорость записи
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Аноним (??) on 25-Окт-10, 12:13
	> Каких задач? > Хранения? угу. т.к. это работает только для memory only. > Доступа? не знаю что это за задача такая. Встроенного шардинга вроде нет, а то, что есть для mysql использовать нельзя, т.к. другой апи. > Скорости? какой? на чтение из кеша - решает. На запись и чтение диска - нет. > Надежности? мм... mysql не самая надежная бд. > Задержки? Все показатели выше, чем > у того же Redis http://code.google.com/p/redis/wiki/Benchmarks очень хорошо. (что я и написал)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от аноним on 25-Окт-10, 13:28
	_поэтому_
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от pro100master (ok) on 25-Окт-10, 14:59
	> угу. т.к. это работает только для memory only. только вот ведь незадача - это попрежнему БД на файлах. Обидно, да? :) >не знаю что это за задача такая. Встроенного шардинга Доступа - в смысле задержек. Они меньше. >какой? на чтение из кеша - решает. На запись и чтение диска - нет. в NOSQL запись... там вообще его нет, только временное хранение :) Сейчас допилят постоянное и они станут не быстрее традиционных sql. > мм... mysql не самая надежная бд. а NoSQL вообще понятие "надёжность" отсутствует. Или непонимай? > очень хорошо. (что я и написал) подозреваю, что и здесь вы "прочитали" только то, что хотели бы видеть - задержки ниже, чем у редиса (показатель выше) :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Аноним (??) on 25-Окт-10, 15:14
	Так и есть. От данных, что от них нам нужно -- чтоб они были в виде одного большого куска (блоба), а к нему была приделана куча вторичных индексов. Ну, и чтоб при добавлении/удалении  блобов вторичные индексы автоматически обновлялись. А Кодд тихо курит в сторонке.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Ананимуз on 25-Окт-10, 18:49
	2.53GHz x8, 32 гига, 3 Гигабита, это вполне обычное железо. А необычное, это что?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+2 +/–
	Сообщение от Stax (ok) on 25-Окт-10, 19:11
	Ну видимо имеется ввиду "бюджетный сервер", а не мощный сервер БД. В реальных задачах под БД может приобретаться очень дорогое железо - x86 с несколькими процессорами (напр. 4 проца и 96 гигов памяти и пара полок дисков - вполне себе обычный сервер под рабочую нагрузку), либо не x86 вообще, что еще дороже. Кто-то до кластеров докатывается, что безумно сложно и так же безумно дорого. Тут же кто-то в ветке про мейнфреймы кто-то доказывал, почему они так хороши под БД, где нужно хорошее масштабирование. Этот простенький сервер, в который разве что воткнули сетевушку о четырех интерфейсах и памяти побольше (ну потянет оно тысяч на 5-6 долларов, возможно) - железо уровня типичного современного десктопа по производительности, и в 10-50 раз дешевле многих мощных серверов БД :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+2 +/–
	Сообщение от pavlinux (ok) on 25-Окт-10, 21:09
	> История о том, как достичь 750,000 запросов в секунду История о том, как достичь 750,000 ответов в секунду, надо бы...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от Knuckles (ok) on 25-Окт-10, 23:16
	> угу. т.к. это работает только для memory only. только вот ведь незадача - это попрежнему БД на файлах. Ты статью-то читал? Дикий прирост производительности достигается засчет отказа от парсера SQL-запросов. Который, однако, дает лишь мизерную задержку по сравнению с чтением данных с диска. Поэтому, если БД не полностью в памяти - все это нахер не нужно, ибо боттлнек будет в другом месте.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Использование MySQL как NoSQL для достижения 750 тыс. запрос..."	+/–
	Сообщение от pro100master (ok) on 26-Окт-10, 01:05
	Для баз до 100 гигов, а это не такая уж и мелочь для подавляющего большинства более менее серьёзных веб-приложений, не выделять память для базы может только религиозно озабоченный олигофрен или толстосумм. Это не то чтобы повод поспорить, просто опыт. Опять же - с другой стороны? сильноутрамбованные раиды неплохо держат конкуренцию с памятью - при таких объемах, масштаб потерь ничтожен, хоть и сильно упирается в рандом.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема