php: создание логики автоматического разделения базы данных?

Question

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

У нас есть веб-приложение, построенное на PHP / mySQL, чтобы упростить его. Таблицы в базе данных могут увеличиваться в размере - легко может быть несколько миллионов записей, поэтому здесь возможно использование шардинга таблицы.

Вот как я представил процесс для работы:

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

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

Будет ли это хорошим способом справиться с большим объемом данных и поддерживать размеры индекса на достаточно низком уровне?

Спасибо

Answer 1

Если вы заранее планируете возможность огромного роста (например, игра стала вирусной), вы можете выполнить те же действия, что и раньше, и перейти на NoSQL.

Couchbase / полномочия Zinga (и личный фаворит)
Apache Cassandra / полномочия Twitter
mongoDB / powers Craiglist

Но вы создаете сайт в php / MySQL, чтобы "упростить" , поэтому не заново изобретайте колесо для решения чрезвычайно большой проблемы .

Не связывайтесь с данными.Перейти на проверенное решение.MySQL включен.

Answer 2

Вы должны использовать горизонтальное разделение, разделить таблицу по количеству записей, скажем, каждый раздел будет иметь миллион записей, таким образом, mysql будет внутренне обрабатывать разделение, и, кроме того, вместо одного большого индекса, индексы будут разделены а также.

Подробнее здесь http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 3

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

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

Answer 4

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