Необходимо создать хранилище, размер которого постоянно увеличивается [закрыто]
Во-первых, по причинам безопасности и другим причинам я не смогу использовать S3 или другое подобное решение.
У меня есть сервер хранения, на котором у меня был диск объемом 1 ТБ. У меня работает сервер Mysql. Данные постоянно начинают добавляться в базу данных нашими компьютерами со скоростью около 1 ГБ в час. Так что примерно через месяц у меня закончится память.
Я хочу иметь возможность добавлять новые жесткие диски и подключать другие системы к сети и связывать хранилище. Например: если я свяжу еще одну систему объемом 1 ТБ, я хочу, чтобы доступное хранилище для базы данных MySQL составляло 2 ТБ. то есть: распределено по двум системам.
Вариант балансировки нагрузки тоже был бы отличным. Т.е. Сервер MySQL на обеих системах должен иметь доступ к базе данных.
Как я могу этого добиться (предпочтительно решения с открытым исходным кодом).
I'll take a punch here and assume that you aren't really interested in combining storage hooked up to several different physical machines as is indicated in your question, but rather just want to be able to grow the storage solution on a single host as your storage needs grow.
If that is the case, I suggest that you take a very close look at ZFS. It is designed specifically to be able to deal with situations like this (among other things), and it is a general-purpose file system.
There is a Linux implementation which unfortunately is known to still experience hiccups under certain use scenarios, or if you prefer rock-solid stable you can host the files on e.g. a FreeBSD host and share them over NFS or SMB, or even just run the database on a FreeBSD system. I don't see you specifying the OS, but your mention of MySQL and preferring open source solutions do point toward *nix. The main caveat is that you really want to go 64-bit and have lots of RAM for ZFS to be really happy, but that shouldn't be as much of a concern today as it has been historically.
On ZFS, you work with what is known as zpools, which are basically somewhat like what you might otherwise think of as file systems. Each zpool is made up of one or more vdevs, which in turn each is made up of one or more physical (or logical) devices. On the entire zpool, you can create what in ZFS terminology is called file systems (separately mountable hierarchies). By adding additional physical devices to a new or existing vdev, the file system automatically makes available and will use the additional storage capacity gained (if any; e.g., if you add a mirror device to a vdev, no additional storage space is gained although you gain redundancy). Adding devices is a completely transparent, online operation; hence, if the storage device itself is hot-pluggable, it is possible to build a storage solution that has zero downtime during capacity upgrades.
You could consider the use of LVM as a file system, but it imply to modify your file system wich can be critical. nice explanation here : https://wiki.ubuntu.com/Lvm
Если вы буквально получаете гигабайты в час в непрерывном, нескончаемом потоке, тогда выбор дизайна ограничен. Вы можете поставить в очередь все новые данные на одном компьютере, который передает их в базу данных MySQL. Таким образом вы можете отключить базу данных MySQL для обслуживания: для добавления дисков, подключения к новым сетям SAN и т. Д.
Машина очереди предоставит вам столько времени на обслуживание, сколько она может хранить данные, но помните, что при повторном подключении к серверу MySQL потребуется наверстать упущенное. Например, вы можете обнаружить, что если машина очереди используется для хранения 4 часов невыполненной работы, может потребоваться 8 часов, чтобы очистить эту невыполненную работу на сервере MySQL; теперь он выполняет вдвое больше операций INSERT.
Совет: Если вы создадите такую машину очереди, вам будет полезно настроить панель мониторинга, которая записывает, как долго пакеты ожидают, прежде чем они будут отправлены на сервер MySQL. Статистика по времени ожидания поможет вам управлять системой. Например, если вы построите график 7-дневных скользящих данных, значение 90 процентилей будет хорошим индикатором общего состояния здоровья. Когда это значение высокое, будьте бдительны. Что-то не так. Вы можете построить график 90 процентилей для данных за каждую неделю; это позволит вам увидеть, становитесь ли вы лучше или хуже со временем.
Запускать новый сервер MySQL каждый раз, когда вы почти полностью заполнены. Перепишите клиентское программное обеспечение, чтобы получить доступ к правильному серверу MySQL в зависимости от даты, в которой им нужна информация.
Конечно, вам нужны данные, которые можно разделить по метке даты. Запросы, которые должны охватывать серверы, должны будут запросить каждый из них и объединить результаты. Присоединиться будет сложно. Однако, учитывая, что вам нужно бесконечное хранилище, вам придется пойти на компромисс в другом месте. Вы не можете иметь бесконечное хранилище и по-прежнему использовать MySQL.
Это отлично подходит для любой базы данных, в которой хранятся журналы или другие архивные данные, которые накапливаются, но не изменяются. Такие данные также легко разделить по метке даты.
Это схема, которую Twitter использовал изначально. У них был один сервер MySQL для архивирования старых твитов; когда он заполнился, они запустили новый сервер. Поиск по запросу «Все, что твитнул пользователь X» отправлял запрос на каждый сервер, начиная с самого нового и заканчивая сервером, на котором хранился архив при создании учетной записи. Все старые серверы были настроены с репликами только для чтения; столько, сколько нужно для выполнения того количества запросов, которые им приходилось обрабатывать. Таким образом, система может масштабироваться в обоих направлениях: увеличивать масштаб (переход к следующему серверу для большего пространства) и горизонтальный размер (добавление большего количества реплик для большей нагрузки).
Однако в конечном итоге вы обнаружите, что реляционная база данных ужасна выбор для хранения журналов или других архивных данных, которые накапливаются, но не меняются. Вставка нескольких строк за один раз включает блокировку, которая замедляет процесс и является расточительной, если вы можете гарантировать, что все данные будут «записаны один раз».
Twitter со временем перешел на другую технологию хранения, и вы обнаружите, что хотите сделать то же самое. Вам нужно будет выбрать систему, рассчитанную на бесконечный рост за счет добавления новых машин. Затем система отслеживает, какие машины хранят какие данные, и даже если вы отправляете свои запросы на главный узел, она делает правильные действия, чтобы найти результаты. К таким системам относятся: MongoDB, Hbase, CouchDB и, я думаю, Riak.
Если ваши данные не могут быть легко разделены, этот ответ вам не поможет. В этом случае вам нужно будет подумать о добавлении все большего объема хранилища в существующую систему. Одним из решений является добавление большого количества дисков в сеть SAN и подключение их к машине.
Затем система отслеживает, какие машины хранят какие данные, и даже если вы отправляете свои запросы на главный узел, она делает правильные действия, чтобы найти результаты. К таким системам относятся: MongoDB, Hbase, CouchDB и, я думаю, Riak.Если ваши данные не могут быть легко разделены, этот ответ вам не поможет. В этом случае вам нужно будет подумать о добавлении все большего объема хранилища в существующую систему. Одним из решений является добавление большого количества дисков в сеть SAN и подключение их к машине.
Затем система отслеживает, какие машины хранят какие данные, и даже если вы отправляете свои запросы на главный узел, она делает правильные действия, чтобы найти результаты. К таким системам относятся: MongoDB, Hbase, CouchDB и, я думаю, Riak.Если ваши данные не могут быть легко разделены, этот ответ вам не поможет. В этом случае вам нужно будет подумать о добавлении все большего объема хранилища в существующую систему. Одним из решений является добавление большого количества дисков в сеть SAN и подключение их к машине.