База данных, которая может обрабатывать> 500 миллионов строк

Я ищу базу данных, которая могла бы обрабатывать (создать индекс в столбце за разумное время и предоставить результаты для отдельных запросов менее чем за 3 секунды) более 500 миллионов строк. Будут ли Postgresql или Msql на низкоуровневой машине (Core 2 CPU 6600, 4 ГБ, 64-разрядная система, Windows VISTA) обрабатывать такое большое количество строк?

Обновление. Задавая этот вопрос, я ищу информацию, какую базу данных я должен использовать на машине низкого уровня, чтобы предоставить результаты для выбора вопросов с одним или двумя полями, указанными в разделе where. Нет подключений. Мне нужно создавать индексы - для достижения достаточной производительности для выбранных запросов не требуется таких возрастов, как на mysql. Этот компьютер является тестовым компьютером для проведения эксперимента.

Схема таблицы:

 create table mapper {
        key VARCHAR(1000),
        attr1 VARCHAR (100),
        attr1 INT,
        attr2 INT,
        value VARCHAR (2000),
        PRIMARY KEY (key),
        INDEX (attr1), 
        INDEX (attr2)   
    }

Ответ 1

MSSQL может обрабатывать многие строки просто отлично. Время запроса полностью зависит от гораздо большего количества факторов, чем просто количество строк.

Например, он будет зависеть от:

сколько соединений связано с этими запросами.
насколько хорошо настроены ваши индексы.
сколько бара находится в машине
скорость и количество процессоров
тип и скорость шпинделя жестких дисков
размер строки/количества данных, возвращаемых в запросе
Скорость/задержка сетевого интерфейса

Очень легко иметь небольшую таблицу (менее 10 000 строк), на которую потребуется выполнить пару минут для выполнения запроса. Например, используя множество объединений, функции в предложении where и нулевые индексы на процессоре Atom с 512 МБ общего бара.;)

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

Все это сводится к тому, сколько денег вы хотите потратить, качество команды разработчиков и размер строк данных, с которыми вы имеете дело.

UPDATE Обновление из-за изменений в вопросе.

Количество информации здесь еще недостаточно, чтобы дать реальный ответ. Вам просто нужно будет его протестировать и при необходимости отрегулировать свой дизайн базы данных и оборудование.

Например, я мог бы легко иметь 1 миллиард строк в таблице на машине с этими спецификациями и запускать запрос "select top (1) id from tableA (nolock)" и получать ответ в миллисекундах. Точно так же вы можете выполнить запрос "select * from tablea", и это займет некоторое время, потому что, хотя запрос выполняется быстро, передача всех этих данных через провод занимает некоторое время.

Точка, вам нужно протестировать. Это означает, что вы устанавливаете сервер, создаете некоторые из ваших таблиц и заполняете их. Затем вам нужно пройти настройку производительности, чтобы правильно получить ваши запросы и индексы. В рамках настройки производительности вы обнаружите не только то, как необходимо реструктурировать запросы, но и точно, какие части машины могут быть заменены (то есть: диск, больше бара, процессор и т.д.) На основе блокировки и типы ожидания.

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

Ответ 2

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

Я бы начал с PostgreSQL, это бесплатно и не имеет ограничений на ОЗУ (в отличие от SQL Server Express) и никаких потенциальных проблем с лицензиями (слишком много процессоров и т.д.). Но это также моя работа:)

Ответ 3

Практически каждая не-глупая база данных сегодня может обрабатывать миллиард строк. 500 миллионов выполнимо даже на 32-битных системах (хотя 64 бит действительно помогает).

Основная проблема:

Вам нужно иметь достаточное количество оперативной памяти. Сколько будет достаточно, зависит от ваших запросов.
Вам нужно иметь достаточно хорошую дисковую подсистему. Это в значительной степени означает, что если вы хотите делать большие выборы, то одно блюдо для всего полностью исключено. Для обработки нагрузки ввода-вывода требуется много шпинделей (или SSD).

Как Postgres, так и Mysql могут легко обрабатывать 500 миллионов строк. На правильном оборудовании.

Ответ 4

То, что вы хотите посмотреть, - это ограничение размера таблицы, которое накладывает программное обеспечение базы данных. Например, на момент написания статьи MySQL InnoDB имеет предел в 64 ТБ за таблицу, а PostgreSQL имеет предел 32 TB за стол; не ограничивает количество строк в таблице. Если они правильно настроены, эти системы баз данных не должны иметь проблем с обработкой десятков или сотен миллиардов строк (если каждая строка достаточно мала), не говоря уже о 500 миллионах строк.

Для обеспечения максимальной производительности при работе с чрезвычайно большими объемами данных вам должно быть достаточно места на диске и хорошая производительность диска, что может быть достигнуто с помощью дисков в соответствующем RAID-массиве и больших объемах памяти в сочетании с быстрым процессором (процессорами) серверные процессоры Intel Xeon или AMD Opteron). Излишне говорить, что вам также необходимо убедиться, что ваша система базы данных настроена для оптимальной производительности и что ваши таблицы индексированы правильно.

Ответ 5

В следующей статье рассматривается импорт и использование таблицы строк 16 млрд. в Microsoft SQL. http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table.

Из статьи:

Вот несколько моих дистиллированных советов:

Чем больше данных у вас есть в таблице с определенным кластерным индексом, тем больше медленнее становится импортировать в него несортированные записи. В какой-то момент, он становится слишком медленным, чтобы быть практичным. Если вы хотите экспортировать таблицу к наименьшему возможному файлу, сделайте его родным. Это лучше всего работает с таблицами, содержащими в основном числовые столбцы, потому что theyre больше компактно представленный в двоичных полях, чем символьные данные. Я упал ваши данные являются буквенно-цифровыми, вы вряд ли выиграете, экспортировав их в собственный формат. Не допускать добавление нулей в числовых полях уплотнить данные. Если вы разрешаете поле быть нулевым, поля двоичное представление будет содержать 1-байтовый префикс, указывающий, сколько байты данных. Вы не можете использовать BCP больше, чем 2 147 483 647 записей, поскольку переменная счетчика BCP является 4-байтовым целое число. Я не смог найти ссылку на это на MSDN или Интернет. Если ваша таблица состоит из более чем 2 147 483 647 записей, вам придется экспортировать его в куски или написать собственную процедуру экспорта. Определение кластерного индекса в предварительно заполненной таблице занимает много диска пространство. В моем тесте мой журнал взорвался в 10 раз от первоначального размера таблицы до завершения. При импорте большого количества записей с использованием BULK INSERT, включите параметр BATCHSIZE и укажите, как много записей для фиксации за раз. Если вы не включите этот параметр, весь ваш файл импортируется как одна транзакция, которая требует много бревенчатого пространства. Самый быстрый способ получения данных в таблицу с кластеризованный индекс должен предварительно определить данные. Затем вы можете импортировать его используя оператор BULK INSERT с параметром ORDER.

Даже это мало по сравнению с базой данных Nasdaq OMX с несколькими петабайтами, на которой хранится десятка петабайт (тысячи терабайт) и триллионы строк на SQL Server.

Ответ 6

Вы проверили Кассандру? http://cassandra.apache.org/

Ответ 7

Как уже упоминалось, вся БД сегодня может справиться с этой ситуацией - вы хотите сосредоточиться на своей подсистеме ввода-вывода на диске. Вам необходимо сконфигурировать ситуацию с RAID 0 или RAID 0 + 1, бросая столько же шпинделей, сколько вы можете. Кроме того, разделите логические диски Log/Temp/Data на производительность.

Например, скажем, у вас 12 дисков - в вашем RAID-контроллере я бы создал 3 раздела RAID 0 из 4 дисков. В Windows (пусть говорят) отформатируйте каждую группу как логический диск (G, H, I) - теперь при настройке SQLServer (допустим) назначьте tempdb в G, файлы журнала в H и файлы данных на I.

Ответ 8

У меня мало информации о том, какая из них лучше всего использовать, но, возможно, этот совет поможет вам получить некоторую скорость, которую вы ищете.

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

CREATE TABLE BigStrings (
   BigStringID int identity(1,1) NOT NULL PRIMARY KEY CLUSTERED,
   Value varchar(6000) NOT NULL,
   Chk AS (CHECKSUM(Value))
);
CREATE NONCLUSTERED INDEX IX_BigStrings_Chk ON BigStrings(Chk);

--Load 500 million rows in BigStrings

DECLARE @S varchar(6000);
SET @S = '6000-character-long string here';

-- nasty, slow table scan:
SELECT * FROM BigStrings WHERE Value = @S

-- super fast nonclustered seek followed by very fast clustered index range seek:
SELECT * FROM BigStrings WHERE Value = @S AND Chk = CHECKSUM(@S)

Это не поможет вам, если вы не выполняете точные соответствия, но в этом случае вы можете посмотреть полнотекстовую индексацию. Это действительно изменит скорость поиска в таблице с 500 миллионами строк.

Ответ 9

Мне нужно создать индексы (которые не занимают столько времени, как на mysql), чтобы добиться достаточной производительности для моих запросов выбора

Я не уверен, что вы подразумеваете под "созданием" индексов. Это обычно одноразовая вещь. Теперь это типично при загрузке огромного количества данных, как вы могли бы это сделать, отбрасывать индексы, загружать свои данные и затем добавлять индексы назад, поэтому загрузка данных происходит очень быстро. Затем, когда вы вносите изменения в базу данных, индексы будут обновляться, но они не обязательно должны создаваться каждый раз, когда выполняется ваш запрос.

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

Точка выше о контрольной сумме выглядит интересной, и это может быть даже индекс на attr1 в той же таблице.