Базы данных

[Drunk Monk]

Нужно замутить базу, где будет порядка 200-300 тысяч таблиц. Структура таблиц, если важно - `i` int(11) NOT NULL, `c` int(11) NOT NULL, UNIQUE KEY `i` (`i`)

Кто подскажет, оно не наебнется от одного факта такого количества таблиц?
Или имеет смысл memcacheDB пробовать, или может Редис какой-нибудь?

[Юнга]

вывод в топ - в паблике, работа с бд - в приватах.. куда катится этот мир

[Drunk Monk]

скинул асю

[chesser]

Сообщение от Drunk Monk

Каждая таблица описывает связь одного из 200к объектов с некоторыми другими через записи вида key-value. Если все писать в одну таблицу, будет миллионов 8-10 записей, что уже наверняка будет тормозить выборки.

если про mysql:

8-10 лямов - это хуйня, тем более у тебя поля короткие, можно даже все в памяти уместить. Индекс будет тоже хорошим, мелким. подтюнить my.cnf и все будет летать, я сто раз так делал

только что глянул свою одну табличку, у меня 100 лямов строк, все умещается в памяти, считываю и записываю в таблицу со скоростью 120к операций в секунду, при том это атомарные операции.

про редис: там вроде ограничение 255 баз )) если я правильно помню

если надо key-value - делай key-value, я тоже туда перехожу с моими лямами, там можно до 300к/с и выше разогнать

в mysql одна таблица - это 3 файла в одной директории, представь у тебя будет 900к файлов в папке.

судя по задаче тебе не надо столько таблиц.
По правильной структуре БД структура таблицы должна быть уникальна. Про это можно почитать, если в гугле набрать "нормальные формы БД"

короче, для тестов пробуй мускуль с 10млн записями.
по той схеме как предложил pesdexx у тебя будет 3 поля по 4 байта = 12 байт. Предположим у тебя 2гига оперативы их которых 500М ушло системе, осталось 1,5гига:
1500000000/12 = 125M - столько влезет в память. Ну хуй с ним, раздели на 10, чтобы учесть накладные расходы содержания этих ячеек в памяти, хранение индекса и тд, получится то, что тебе надо.

пихаешь все записи в память, т.е. типа таблиц будет MEMORY
если нет кверин с order by и запросов на сравнение интервалов типа <, > - то делай вместо обычных индексов HASH индексы - все вообще летать будет, так что охуеешь даже... я сто раз так делал

у меня еще много рецептов, но думаю хватит

[Drunk Monk]

Спасибо. Тут по ходу наполнения этих таблиц появляются новые обстоятельства, но насчет "структура таблицы должна быть уникальна" призадумался. Идейно мысль верна, но я делал эксперимент один, в результате которого оказалось, что 1000 определенным образом нарезанных таблиц в разы лучше, чем одна большая.

А сколько твои 100 лям держат конкурентных запросов?

[rushter]

оказалось, что 1000 определенным образом нарезанных таблиц в разы лучше, чем одна большая.

Бред полнейший.

[chesser]

Сообщение от Drunk Monk

А сколько твои 100 лям держат конкурентных запросов?

а ты, кстати, про конкурентные запросы ничего нам не говорил вроде

120к атомарных операций чтения/вставки в секунду. Для лучшего эффекта и выжимания последнего герца из проца я хуячу эти запросы в N потоков, N равно примерно 5-10. По сути я эмулирую MapReduce на LAMPе, будь он не ладен.
Что тут считать конкурентными запросами? я могу и 100 потоков запустить, тогда скорость и суммарная производительность просядет, вместо 120к/c будет может 60к/c
Но у меня задача заключается не обеспечить конкурентность, а постороение и управление большим кол-вом связей большого кол-ва объектов Но т.к. кол-во связей милионы, а у каждой связи есть свойства и получаются уже миллиарды, то хочется строить их быстро, а то можно не дожить.

На редисе получается в районе 300к в секунду, но там есть нюансы, например мулти-запросы....ну архитектурные моменты, которые могут увеличить или уменьшить скорость, оптом то обычно дешевле (быстрее)

[chesser]

Сообщение от rushter

Бред полнейший.

нет, не бред, а кривая настройка my.cnf
тупо индекс в буфер не пролазеет у большой таблицы, а у мелких нормально.

Но если все настроено как надо, то да, одна таблица лучше

Drunk Monk,
вот еще ознакомься: http://www.mysqlperformanceblog.com - авторитный рес
ну и вот про этот упомянуть стоит: http://sqlinfo.ru/forum/

[Drunk Monk]

Не то, что кривая, скорее дефолтная

[chesser]

Сообщение от Drunk Monk

Не то, что кривая, скорее дефолтная

а задача то у тебя не дефолтная, поэтому надо крутить настроечные ручки

[imgreen]

под key-value юзай соответстующие бд, какие ты привел в пример, тут реляционные бд отсасывают