|
Задавайте вопросы, мы ответим
Вы не зашли.
Привествую всех форумчан и Администраторов замечательного форума!
Хотел бы получить от вас советы, подсказки, а может и конкретные предложене касательно создания БД, которая обеспечила б надежное хранение данных, а самое главное, предоставила быстрый поиск данных.
Задум следующего характера:
Предположем, есть огромная база данных, по которой нужно произвдить поиск нужной информации.
Эта база данных постоянно будет разрастаться. К примеру, в нее будут загружаться прайсы товаров или ж другими способами пополняться данные (к примеру те самые краулеры, которые собирают информацию из web). Так вот, необходимо правильно спроэктировать БД, чтобы затем построить эффективный алгоритм поиска.
Здесь я не в даюсь в детали, просто хочеться услышать мнение более опытных разработчиков которые работали с терабайтными массивами данных и производили по них поиск.
Разумеется, здесь можно применить много методик (секционирование, или построение индексов и т.д...)
Так вот, что посоветуете: какой движок выбрать, как обеспечить максимальную производительность при поиске информации в огромных массивах данных - тоисть все сводиться к тому, чтобы изначально правильно спроэктировать такое хранилище.
Я понимаю, мои вопросы имеет более абстрактный подход, но все таки хочеться услышать мнение других - чтобы затем двинаться в правильном русле...
Да здравствует великий Google, который сумел создать мировое хранилище всей информации 
ведь они смогли это сделать...
Спасибо!!!
Неактивен
yuriy, Вы задали очень много вопросов, даже сразу не понятно сколько именно. Вопрос о надежности хранения решается дублированием информации и бэкапом (все зависит от базового решения). Как гугл и другие достигли эффекта - быстрее всего понять из докладов конференции Highload (если будете приобретать доступ к онлайн-просмотрам, используйте код Rty10, который дает скидку 10% - он работал во время конференции и, надеюсь, еще работает). Хотел сказать, что это не реклама, но это реклама, так как мы сотрудничаем с Highload, но все равно там наиболее развернутый ответ на вопрос об архитектуре высоконагруженных систем.
Что касается терабайта - поиск по индексу будет работать достаточно быстро. Для поиска текста протестируйте полнотекстовый поиск, сфинкс или собственную систему индексации. Крупные компании многие решения пишут специально, а не полагаются на стандартные решения. Чтобы выдержать нагрузку - вам нужно использовать шардинг, то есть разносить информацию по разным машином по id элемента.
Неактивен
Скажите, пожалуйста, что вы думаете касательно создания кластирных индексов?
Читал, что они позволяют во многом ускорить чтение данных при больших объемах.
И еще, подскажите, какую лучше использовать СУБД для работы с большими объемами данных. MySQL не самый лучший вариант построение архитектуры... куда копать?
Спасибо!
Неактивен
Сравниваете производительность для конкретной задачи. Кластерные индексы (в Innodb), если грубо, то ускоряют, если работаете с первичным ключом и данные большие (в каждой записи).
Вы не сказали какая задача, а спрашиваете про решение. MySQL подходит и для больших объемов и для больших нагрузок, например, см. мой доклад http://sqlinfo.ru/a/i/rubtsov_xtables.ppt
другие базы также можно использовать. Опять не реклама, но советую посмотреть труды хайлоад, там представлены разные работающие решения.
Неактивен
Планируется создать базу данных для загрузки прайсов, размеры которых будут большими. Соотвественно, перед тем как начинать разработку хотелось сначала определиться какую из СУБД выбрать. Если вы говорите что MySQL вполне справиться с терабайтными данными, - это обнадеживает. Тогда вопрос: Таблица содержит сотни миллионов записей. Производить поиск по определенному полю табл. (даже если использвть индексы с использованием опретора LIKE %), наверное очень напряжно будет? Здесь, навреное нужен определенный алгоритм поиска (поиск на по саммым данным, а по хешу, как вариант)...
Неактивен
поиск по внутреннему (объемному) содержимому прайсов или по каким-то метаданным?
Неактивен
Поиск планируется производить по внутренним данным, которые будут загружаться в БД по определенному шаблону.
А что вы подразумеваете под метаданными?
Отредактированно yuriy (01.12.2013 01:28:54)
Неактивен
То есть поиск идет по данным, которые не занимают большой объем, а больший объем занимают некие данные, в которых искать нельзя? В этом случае миллионы строк - это не много. Какой объем тех данных, в которых нужно будет искать?
Неактивен
Ситуация в следующем: есть табл. к примеру 6-тью полями. Поиск планируется производить по 2-ум полям (это название товара и его код - артикул). Пользователь вбивает запрос, система должна выдать релевантный ответ (учитывая поиск по 2 полям).
Остальные поля - это скажем дополнительная информция по которой поиск не будет проводиться она будет выводиться уже при результатах поиска.
Сколько будут занимать данные, не готов вам сказать - но учитывая то, что в 1 прайсе может содеражться порядка сотен тысяч позицый умноженое на десятки тысяч пользователей - цифра получается не малая... так вот, если в расчет брать БД MySQL - движок myisam + не использовать никаких объединений + индексы, то при штатном поиске с помощью оператора LIKE % - трудно сказать, что поиск будет быстрым... не знаю, правда, нужно безусловно тестировать, - но это как мне кажеться не совсем хорош подход для построения модели...((( для этого используется навреное другой подход, но вот какой, пока не знаю еще...
Отредактированно yuriy (01.12.2013 02:01:22)
Неактивен
Прошел год, но добавить что-то конструктивное к этому обсуждению сложно
http://sqlinfo.ru/forum/viewtopic.php?id=6178
Неактивен
Уже добавили)))
Неактивен
