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

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

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

13.12.2008 16:18:12
Можете ли вы предоставить некоторые подробности о том, как данные будут доступны?
Robert Gamble 13.12.2008 16:29:15
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

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

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

2
13.12.2008 22:14:57

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

1
13.12.2008 16:38:07

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

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

6
13.12.2008 21:15:38

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

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

0
13.12.2008 17:39:48

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

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

0
13.12.2008 20:52:48

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

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

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

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

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

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

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

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

0
13.12.2008 22:20:01
ну, мне нужно заполнить пробелы в таблице, если таковые имеются, что проще с mysql, потому что данные будут заполняться несколькими сценариями
James Hartig 24.12.2008 04:34:41

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

0
6.02.2012 19:05:15