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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Из статьи:

Вот несколько советов из моего опыта:

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 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 миллионами строк.

Answer 9

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

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