|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Требуется создать на сайте поиск предложений от десятка фирм. Предложения предполагалось импортировать с сайтов фирм, используя XML-шлюзы. Начал делать и голова пошла кругом от объемов.
Лишь у одной фирмы насчитывается порядка 8 тыс. категорий и в каждой порядка 30 - 80 тыс. наименований. Сделал пробную загрузку лишь 200 категорий с одной фирмы, размер базы MySQL уже получил 460 Мб. Нетрудно посчитать, что все предложения фирмы - это база порядка 20 Гб. А если еще и десяток фирм учесть, то 200 Гб!
Посмотрел ограничения. Для MySQL 3.23+ база может быть до 8 миллионов терабайт. (2 ^ 63). Т.е. в этом смысле вроде бы никаких проблем. Но какое железо нужно для того чтобы ворочить такую базу? И какую структуру лучше сделать?
Сейчас структура довольно простая:
1. Список предложений в одной таблице BIGINT-значений. Каждое предложение содержит лишь ссылки (десяток цифр) на разные справочники.
2. Собственно, справочники, отдельные таблицы (INT-значений в каждой).
Поиск должен будет представлять собой форму для отбора предложений по параметрам. Отправляя запрос, предполагается, что результат должен появляться через несколько секунд. А что-то я не уверен теперь что это реально.
Выборка - это постранично разбитый список. Для построения выбранной страницы списка потребуется обращение к справочникам, т.е. сложный запрос MySQL.
Буду благодарен выслушать любые советы! Может кто-то делал подобное и поделится опытом, что требуется для реализации подобной задачи.
Неактивен
Слишком общие слова, но, если грамотно сделать базу, то может оказаться не так уже плохо.
Нормальные индексы — и будет работать. Скорее всего, прийдется шардировать.
3.23 — это *очень* старый сервер. Столь же старый, сколь BIGINT *большое* число. В обычный
INT UNSIGNED влезает 4 млрд строк. Даже если у Вас будет 10 тысяч категорий по 100 тысяч
наименований — это 1 миллион строк на фирму. Т.е. Вы сможете обслужить до 4000 таких
фирм. Кажется, хватит 
Неактивен
Спасибо за ответ.
Поисковая форма на сайте должна содержать примерно те же поля на которые ссылаются предложения, т.е. оптимизировать (создать индексы) под любой из видов запроса вроде как не реально. Разве что продумать наиболее частые запросы и создать оптимальные индексы для них.
Ссылку на вестию 3.23 я нашел на википедии. Так то конечно, будет последняя версия базы.
Насчет INT и BIGINT. Я отталкивался от документации:
INT[(M)] [UNSIGNED] [ZEROFILL]
Целое число нормального размера. Диапазон со знаком от -2147483648 до 2147483647.
BIGINT[(M)] [UNSIGNED] [ZEROFILL]
Большое целое число. Диапазон со знаком от -9223372036854775808 до 9223372036854775807.
А, хотя если без знака, то для INT, от 0 до 4 294 967 295.
По максимуму 8 000 кат. * 80 000 наим. * 10 фирм = 6 400 000 000 т.е. не хватает уже. Да плюс еще какие-то предложения могут устаревать и удаляться из базы не сразу.
Мне тут вот какая мысль пришла в голову. Допустим база 200 Гб. Скорость чтения с жесткого диска не более 100 мб/сек. Пусть даже какой-то супер реид на сервере, то все равно не более 500 мб/сек. Т.е. теоретически запрос по базе в 200 Гб может занять 400 секунд. Многовато... Одним сервером всяко похоже не обойтись.
Неактивен
Хм, и правда, как я так считал? Видимо, где-то лишнюю тысячу упустил
Неактивен
