наиболее быстрая субд
 

Здравствуйте!

Прошу совета: какая база данных наиболее подходит для хранения сотен миллионов записей?

Очевидно, при запросе нагрузка получится большой на любую из них, вопрос в том, какая лучше справится с этой нагрузкой, то есть отдаст ответ максимально быстро (желательно не более 2-3 минут).
Также хотелось бы узнать у какой субд больше путей оптимизации для увеличения производительности и какие это пути помимо индексирования.

Ещё один вопрос, который возможно вытечет из предыдущих: что делать если все субд будут довольно долго справляться с нагрузкой, как в этом случае увеличить производительность?

Спасибо!

PS: ну и конечно предстоит долгий процесс испытаний

jah, недостаточно исходных данных для осмысленного ответа.

По существу вопроса: «производительность», «нагрузка» и «подходит для хранения» это разные вещи. Тем не менее, успех реализации определяется преимущественно качественным анализом предметной области и тщательным планированием концептуальной модели базы данных. И только затем переходят к выбору конкретной СУБД. У Вас, к сожалению, предметная область даже примерно не обозначена.

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

например,
структура - одна таблица с двумя строковыми полями по 20 символов
для конкретности, пусть одно поле будет именем человека, а второе - его ником, то есть таблица наводит соответствие между именем и ником
имена могут повторяться, ники изредка тоже
в таблице накопилась сотня миллионов записей
осуществляется один простой запрос на выборку всех имён, у которых, например, ник такой-то

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

далее можно усложнять структуру, запросы и т.п.

Вот про это я и говорил. В этой таблице ни первое, ни второе поле, ни их совокупность не могут выступать в качестве ключевого. Т.е., как минимум нужно будет ещё одно уникальное поле.

Ещё раз:
Ошибки в проектировании структуры обходятся весьма дорого, и псу под хвост идут сотни и тысячи человеко-часов работы.

По сути: на мой взгляд, на объёме 100,000,000*((20+20)*2)/2^30 ≈ 7.45 Gb — за «не более 2-3 минут» справится любой сервер. Даже скрипт на весьма старом железе справляется на текстовом файле (т.е., ни разу не файл прямого доступа) при доступе к нему по OLE DB за немногим большее время:

читать дальше »

Цитата:

Файл лога имел размер 630 915 078 байт, все записи (строки) без условий выбираются примерно за 80 сек. (5 223 755 строк). С условиями (WHERE): 164 117 строк примерно за 70 сек., 2 228 строк примерно за 44 сек., ноль строк примерно за те же 44 сек. WinXP SP2, 512Мб памяти, Celeron D 3.0GHz.

Что уж говорить про SQL сервер на серверном железе.

По вопросам сравнительной производительности конкретных серверов попробуйте задать Ваш вопрос на специализированном форуме, типа SQL.RU и т.п. Правда, боюсь, и там можно будет вместо ответа нарваться на эпичный срач, наподобие этого.

если просто наличие ключевого поля (которое так-то предполагалось) помогает субд ускорить выполнение этого запроса, то я об этом не знал

согласен, для меня это высший пилотаж, поэтому интересны решения применительно к рассматриваемому случаю, записей будут сотни миллионов, это точно, как их дробить или делать что-то ещё, это я и пытаюсь выяснить

у меня ( i3 (2x3.5ГГц) 4Гб ОЗУ ) 2Гб на одном и том же разделе копируются почти 2 минуты
и байт в моём случае на порядок больше получается
понятно, что процедуры в субд специально оптимизированы и не совсем корректно делать такие сравнения, но если на простейшем запросе будут эти 2 минуты, то на более сложных запросах время выполнения увеличится в несколько раз (хотя бы 5-минутная задержка с учётом добавки времени на дальнейшую обработку полученных результатов (например, при использовании в веб-приложении) это в данном случае критично)

на следующей неделе начну тесты на боевом сервере (дома такого нет), поэтому цифры станут точнее

срача не надо, но если есть какие-либо соображения по этом поводу, буду только рад

Нет. Но без наличия ключа Вы не сможете корректно работать с таблицей, поскольку невозможно будет однозначно идентифицировать запись среди прочих: Нормальная форма — Википедия.

«копируются», т.е. читаются, затем записываются. Это один файл или множество? Как с фрагментацией на разделе? Не в том дело.

Наоборот — совсем некорректно.

Возьмите на «поиграться» Скачать Microsoft® SQL Server® 2012 Express с официального сайта Центра загрузок Microsoft (именно на «поиграться/оценить» — у бесплатной версии ограничения: 1 процессор, до 1 Gb памяти, до 10 Gb размер БД).

возможно, в связи с некорректностью дальнейшего сравнения далее засечения времени не анализировал (тип самого диска также имел значение)

да, буду пробовать

подошли к горячему: может есть какие-то соображения по поводу ms sql server, oracle database, mysql или какая-то другая субд имеют преимущества (сами по себе или вкупе со специальными средствами) по отношению к другим при работе с большим количеством записей

Я тут Вам не советчик: ни с Oracle николи не работал, ни с объёмами баз на терабайты.

спасибо и на этом, сам впервые столкнулся с такими объёмами
на данный момент имею только индексирование и, предполагая, что задача уже давно не новая, видимо придётся изобретать велосипед, попутно продолжая искать готовые решения

оттолкнулся отсюда
http://habrahabr.ru/post/147743/

пришёл досюда
http://www.oracle.com/us/products/da...iew/index.html

правда
http://ru.wikipedia.org/wiki/Exalytics