Большой первичный ключ: 1 + миллиард MySQL строк + InnoDB?
используйте этот <i class="far fa-file fa-9x text-info" style="float: left; margin-right:7px;"></i> вместо вашего <i class="far fa-file fa-9x text-info pull-left"></i>
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.6.1/css/all.css">
<div class="card border-secondary my-3">
<div class="card-header">
<h3>Title</h3>
</div>
<div class="card-body text-secondary">
<div class="card-text">
<div class="row align-text-top">
<div class="col px-5 ">
<i class="far fa-file fa-9x text-info" style="float: left; margin-right:7px;"></i>
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
<div class="col">
<asp:fileupload id="fuDocument" runat="server" cssclass="btn btn-secondary" allowmultiple="False" height="200">
<p class="mt-2">
<asp:button id="btnUploadFile" runat="server" text="Υποβολή" cssclass="btn btn-primary" onclick="btnUploadFile_Click">
</asp:button></p>
</asp:fileupload></div>
</div>
</div>
</div>
</div>
</div>
<div id="push"></div>
6 ответов
Единственный категорический ответ должен попробовать обоих и протестировать и видеть то, что происходит.
Обычно MyISAM быстрее для записей и чтений, но не обоих одновременно. Когда Вы пишете в таблицу MyISAM, вся таблица заблокирована, чтобы вставка завершилась. InnoDB имеет больше служебное, но использует блокировку уровня строки так, чтобы чтения и записи могли произойти одновременно без проблем, которым подвергается блокировка таблицы MyISAM.
Однако Ваша проблема, если я понимаю это правильно, немного отличается. Наличие только одного столбца, при этом тот столбец является первичным ключом, имеет важный фактор различными способами, которыми MyISAM и InnoDB обрабатывают индексы первичного ключа.
В MyISAM индекс первичного ключа точно так же, как любой другой вторичный индекс. Внутренне каждая строка имеет идентификатор строки, и индексные узлы просто указывают на идентификаторы строки страниц данных. Индекс первичного ключа не обрабатывается по-другому, чем какой-либо другой индекс.
В InnoDB, однако, первичные ключи кластеризируются, означая, что они остаются приложенными к страницам данных и удостоверяются, чтобы содержание строки осталось в физически отсортированном порядке на диск согласно первичному ключу (но только в рамках единственных страниц данных, которые самих могли быть рассеяны в любом порядке.)
При этом я ожидал бы, что InnoDB мог бы иметь преимущество в том, который должен будет по существу сделать MyISAM, двойная работа - пишет целое число однажды в страницах данных и затем пишет это снова в индексных страницах. InnoDB не сделал бы этого, индекс первичного ключа будет идентичен страницам данных и должен был бы только записать однажды. Это должно было бы только управлять данными в одном месте, где MyISAM должен будет напрасно управлять двумя копиями.
Для любого механизма устройства хранения данных, делая что-то как минута () или макс. () должно быть тривиальным на индексированном столбце или просто проверке существования числа в индексе. Так как таблица составляет только один столбец, никакие поиски закладки даже не были бы необходимы, поскольку данные будут представлены полностью в самом индексе. Это должно быть очень эффективным индексом.
Я также не был бы всем, что волновалось о размере таблицы. Где ширина строки является только одним целым числом, можно соответствовать огромному количеству строк на индекс/страницу данных.
Если у Вас есть индекс на Вашем идентификационном столбце, избранная минута (идентификатор) должна быть O (1), не должно быть большой части требования к памяти для этого.
Если Ваш первичный ключ находится на идентификаторе Твиттера затем, у Вас есть индекс на нем.
Я рекомендовал бы запустить partioning таблица идентификатором или датой. Partioning разделяет большую таблицу на несколько меньших таблиц согласно некоторой определенной логике (как разделение его диапазонами даты), который делает их намного более managable производительностью и памятью мудрый. MySQL 5.1 имеет эту встроенную функцию, или можно реализовать его с помощью настраиваемых решений.
В устройстве хранения данных реализации в плоском файле Вы теряете все преимущества базы данных - Вы больше не можете выполнять запросы, включающие данные.
С одним единственным полем, будучи первичным ключом, только когда-либо добавляя записи, это действительно не подходит для регулярной базы данных.
Для запуска Вы храните вдвое больше информации, поскольку Вы должны с каждым полем, входящим в таблицу данных и индекс.
Как в стороне, реляционная база данных так называется с тех пор, со своей стороны, они связанные с хранилищем данные в одну строку; трудно видеть, как Ваши данные квалифицируют :-) При хранении другого материала также база данных стоила бы того.
Вы не упоминаете, получат ли к данным доступ несколько процессов сразу - в противном случае затем Вам не нужны все преимущества, данные принципами базы данных ACID. Даже если Вы действительно хотите ACID, который может все еще быть достигнут без полноценной базы данных.
Мое первое, хотя должен был бы создать Ваше собственное B-дерево или B +-tree файл данных для хранения идентификаторов Твиттера для предотвращения дублирования данных. Единственные запросы I видят, что Вы делать (на основе вопроса):
- выберите минуту (идентификатор) из tbl; и
- выбрать идентификатор из tbl где идентификатор =?
Первое может быть сделано O (1) путем простого хранения самого низкого в другом файле за пределами структуры B-дерева (и заменяя его, когда Вы получаете более низкий). Я не уверен в экономической модели для этого, если она не должна быстро узнавать, что определенный идентификатор Твиттера не находится в таблице (таким образом, Вы, вероятно, хотели бы макс. также в этом случае).
Вторыми являются стандартные методы поиска дерева, который является тем, что база данных обычно использует под покрытиями так или иначе.
Если эти Идентификационные номера монотонно увеличиваются, и Ваши записи только добавляют данные (никогда не изменяют его), это, вероятно, будет намного быстрее для использования единственного файла. A SELECT min('id') затем просто становится чтением первой строки файла, и что-либо еще - двоичный поиск.
Существует хорошее сравнение механизмов устройства хранения данных на зоне MySQL Dev:
- Архитектура механизма устройства хранения данных MySQL, часть 1: обзор
- Архитектура механизма устройства хранения данных MySQL, часть 2: всесторонний взгляд
- Архитектура механизма устройства хранения данных MySQL, часть 3: детали и сравнение
Из Вашего описания я сказал бы, что MyISAM будет лучше, но он зависит довольно много от сравненного чтения и записи шаблонов Вашего приложения.