Большой первичный ключ: 1+ миллиардов строк MySQL + InnoDB?

Question

Мне было интересно, будет ли InnoDB лучшим способом отформатировать таблицу? Таблица содержит одно поле, первичный ключ, и таблица будет получать 816 тыс. Строк в день (оценка). Это будет очень большой очень быстро! Я работаю над способом хранения файлов (это будет быстрее)? В таблице будут храниться идентификационные номера идентификаторов Twitter, которые уже были обработаны?

Кроме того, оценивается ли использование памяти в операторе SELECT min('id')? Любые другие идеи приветствуются!

Answer 1

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

При хранении в виде простого файла вы теряете все преимущества базы данных - вы больше не можете выполнять запросы с данными.

Answer 2

Единственный окончательный ответ - попробовать оба варианта и проверить, что произойдет.

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

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

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

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

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

Для механизма хранения выполнение чего-либо вроде min () или max () должно быть тривиальным для индексированного столбца или просто проверять наличие числа в индексе. Поскольку таблица состоит только из одного столбца, поиск закладок даже не потребуется, поскольку данные будут полностью представлены в самом индексе. Это должен быть очень эффективный индекс.

Я бы тоже не беспокоился о размере стола. Если ширина строки составляет всего одно целое число, вы можете разместить огромное количество строк на страницу индекса / данных.

Answer 3

Если эти идентификационные номера монотонно увеличиваются, и ваши записи только добавляют данные (никогда не изменяют их), вероятно, будет гораздо быстрее использовать один файл. SELECT min('id') затем просто читает первую строку файла, а все остальное - двоичный поиск.

Answer 4

Я также видел, как некоторые торговые фирмы используют тиковую базу данных, т.е. KDB + http://kx.com/

Answer 5

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

Для начала, вы храните вдвое больше информации, чем нужно, каждое поле входит в таблицу данных и индекс.

Кроме того, реляционные базы данных называются так, поскольку, например, они хранят связанные данные в одной строке; Трудно понять, как соотносятся ваши данные :-) Если бы вы хранили и другие вещи, база данных стоила бы этого.

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

Сначала я хотел бы создать собственный файл данных B-дерева или B + -дерева для хранения идентификаторов твиттера, чтобы избежать дублирования данных. Единственные запросы, которые я вижу, вы делаете (основываясь на вопросе):

• выберите min (id) из таблицы; и
• выберите идентификатор из таблицы, где id =?

Первое можно сделать O (1), просто сохранив самый низкий в другом файле за пределами структуры B-дерева (и заменив его, когда вы получите более низкий). Я не уверен в экономическом обосновании этого, если только это не быстрое обнаружение того, что определенного идентификатора твиттера нет в таблице (так что вы, вероятно, также захотите max в этом случае).

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

Answer 6

В MySQL Dev зоне есть хорошее сравнение механизмов хранения:

• Архитектура MySQL Storage Engine, часть 1: Обзор
• Архитектура MySQL Storage Engine, часть 2: углубленный взгляд
• Архитектура MySQL Storage Engine, часть 3: детали и сравнение

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

Answer 7

Если у вас есть индекс в вашем столбце идентификатора, выберите min (id) должно быть O (1), для этого не должно быть большой потребности в памяти.

Если ваш первичный ключ указан в твиттере, значит, у вас есть индекс.