[Iska]

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

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

[jah]

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

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

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

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

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

[Iska]

структура - одна таблица с двумя строковыми полями по 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 и т.п. Правда, боюсь, и там можно будет вместо ответа нарваться на эпичный срач, наподобие этого.

[jah]

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

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

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

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

По сути: на мой взгляд, на объёме 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 сервер на серверном железе. »

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

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

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

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

[Iska]

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

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

у меня ( i3 (2x3.5ГГц) 4Гб ОЗУ ) 2Гб на одном и том же разделе копируются почти 2 минуты »

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

и не совсем корректно делать такие сравнения »

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

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

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

[jah]

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

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

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

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

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

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

[Iska]

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

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

[jah]

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

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

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

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

правда

This product is not available for purchase in Russia

http://ru.wikipedia.org/wiki/Exalytics

В качестве «инженерного программного обеспечения» (проходящего по прейскуранту для аппаратно-программных комплексов и являющегося фактически обязательным дополнением к ним) поставляется специализированная версия Timesten — «Timesten In-Memory Database for Exalytics» со стоимостью $300 за именованного пользователя или $34,5 тыс. за процессорную единицу[7] (процессорная единица в терминах Oracle означает 2 ядра архитектуры x86-64 или архитектуры SPARC T5, то есть на Exalytics X4-3 при процессорном лицензировании потребуется 20 процессорных единиц — $690 тыс., а на T5-8 — 64 процессорных единицы и $2,208 млн).