Мегабаза и мегавремя выборки

[Fubu_By]

а сколько запросов в секунду будит к твоей таблице? и сколько весит одна запись, какой объём инфы, и вообще какая?

гы, Redis, данные хранятся в ОЗУ, теперь представьте сколько потребуется ОЗУ для хранения миллиарда записей, даже если одна запись будит весить 1байт то 1миллиард байт ~1гиг. поправьте если ошибаюсь

 

[dumber]

Я думал об этом. Хотелось бы услышать проверенные мнения - кто-то уже так делал? Помогло, получилось?

Таблицу с основными данными можно поделить к примеру на несколько, будет почти такой же эффект в плане ускорения поиска по более меньшим таблицам.
Кстати об оптимизациях, в последнем проекте большую базу (все записи с уникальным порядковым номером, но она постоянно дополняется новыми записями ко всему прочему) разрезал на 2 - в первой последние 10к записей - к которым и идет почти 90% запросов, во второй остальные записи.
При увеличении первой базы до 15к записей самые старые 5к скидываются во вторую базу.
Ну и отдельная таблица с 1 записью - до какого номера данные хранятся во второй базе.

 

[venetu]

Очень сильно зависит от того, что у тебя там за запросы. Если нужно только точное вхождение - то да, redis, memcached или даже тупое двоичное дерево - великолепно подойдет.

А если нужен поиск по подстроке - тут уже сильно надо думать с индексами, возможно шардить, как советует dumber, возможно группировать ценой введения минимальной подстроки (как в здешнем поиске, "указанные слова слишком короткие и не были включены в поиск").

Короче, опиши более подробно задачу. Что ты собираешься хранить и каким образом доставать, по каким признакам. Идеально было бы кинуть сюда свои CREATE TABLE и SELECT - а мы уж их пооптимизируем как надо.