Я часто использую SQLite для создания простых программ в компаниях. База данных размещается на файловом сервере. Это работает нормально, пока с базой данных одновременно работают не более 50 пользователей (хотя в зависимости от того, читает она или пишет). Когда их больше, они заметят замедление, если на сервере много одновременной записи, поскольку много времени тратится на блокировки, и нет ничего лучше кеша, поскольку нет сервера базы данных.
Преимущество отсутствия необходимости в сервере базы данных состоит в том, что время, необходимое для создания чего-то вроде корпоративной Wiki или подобного, может быть сокращено с нескольких месяцев до нескольких дней. Часто это занимает несколько месяцев, потому что некоторому ИТ-отделу необходимо заказать сервер, и он должен соответствовать политикам и правилам безопасности компании, и его необходимо разместить на стороннем сервере, размещающем сервер, который портит и размещает его не в том месте. и т. д. и т. д.
Поэтому у меня возникла идея создать сервер распределенной базы данных. Процесс будет следующим: пользователь на компьютере компании редактирует что-то на странице Wiki (которая использует эту базу данных в качестве бэкэнда), для этого он читает файл на локальном жестком диске, в котором указывается IP-адрес последнего настольного компьютера. быть сервером базы данных. Затем он пытается связаться с этим компьютером напрямую через TCP / IP. Если он не ответит, то он прочитает файл на файловом сервере, в котором указан IP-адрес последнего настольного компьютера, который был сервером базы данных. Если и этот сервер не отвечает, его собственный настольный компьютер станет сервером базы данных и зарегистрирует свой IP-адрес в том же файле. Затем может быть выполнен оператор обновления SQL, и другие настольные компьютеры могут подключиться к нему напрямую.
Суть этой архитектуры в том, что чем выше нагрузка, тем лучше она будет работать, поскольку каждый настольный компьютер всегда будет знать IP-адрес сервера базы данных. Кроме того, используя эту настройку, я считаю, что база данных, размещенная на файловом сервере, может обслуживать сотни настольных компьютеров вместо нынешних 50 или около того. Я также не верю, что нагрузка на единственный настольный компьютер, который стал сервером базы данных, когда-либо будет заметной, поскольку на этом рабочем столе не будет операций с жестким диском, только на файловом сервере.
Возможна ли эта идея? Он уже существует? Какая база данных могла бы поддерживать такую архитектуру?
Изменить: я должен отметить, что эта идея не является красивой, стабильной, лучшей практикой или чем-то, чем я действительно гордился бы. Причина, по которой меня все еще интересует осуществимость, заключается в том, что некоторые из моих клиентов - банки, а бюрократия, связанная с получением доступа к базе данных, огромна. Часто спонсор таких проектов должен быть выше уровня вице-президента из-за их крайних соображений безопасности при получении доступа к серверам. Излишне говорить, что это означает, что для создания Wiki необходимо проделать большую работу. Позже, если Wiki окажется успешной, ее, конечно же, следует перенести на соответствующий сервер базы данных.
Edit2: причина этой идеи - снизить риск истощения Writer при использовании SQLite, когда база данных размещена на файловом сервере. Эта проблема описана в разделе 5.1. Вот. Использование настольного компьютера для кеширования наиболее часто используемой информации (например, страниц Wiki) означало бы, что рабочая нагрузка на файловый сервер значительно снизилась бы. Это снова должно улучшить пользовательский опыт. Вы действительно думаете, что я все еще далек от этой идеи?
Возможна ли эта идея?
Нет.
Он уже существует?
Не то, что я знаю о.
Какая база данных могла бы поддерживать такую архитектуру?
См. Выше.
Честно говоря, это действительно плохая идея на многих уровнях. Есть причина, по которой компании хранят важные данные в центре обработки данных. Вы не хотите, чтобы бизнес-приложения зависели от X числа работающих настольных компьютеров. Другой проблемой могут быть брандмауэры - во всех средах, кроме небольших, не будет никаких гарантий, что Desktop X сможет взаимодействовать с Desktop Y, и удачи в том, что изменение брандмауэра пройдет мимо вашей сетевой команды.
Есть ли причина, по которой у вашей компании нет центрального хорошо обслуживаемого сервера базы данных, который может использовать это приложение? Нет причин, по которым вики компании должен нуждаться в собственном сервере базы данных.
Этот вопрос не относится к системному администрированию, но когда я его прочитал, сработало так много тревожных сигналов, что мне просто нужно было ответить.
Я действительно должен сказать вам, что вся ваша концепция настолько далека от истины, что вы не найдете никого, кто бы это делал. Во-первых, SQLite не подходит для такой работы, и тот факт, что вы добились некоторого успеха с ним, больше связан с удачей, чем с чем-либо еще.
В вашем плане так много дыр, что я действительно не знаю, с чего начать, но я скажу вам, что это будет слишком сложная система, которая окажется невероятно ненадежной и плохо работающей.
Твой комментарий
время на создание чего-то вроде Wiki компании или подобного может быть сокращено с нескольких месяцев до нескольких дней
О многом мне говорит. Настройка вики обычно занимает всего несколько минут, и у любой приличной вики-системы будут помощники для ускорения импорта данных из других систем.
Я предлагаю вам отказаться от ваших текущих дизайнерских идей и посмотреть, как такие вещи делают другие. Используйте любую из распространенных вики-систем (я предпочитаю MediaWiki) с обычной системой баз данных (MySQL очень популярен), и вы не только сэкономите огромное количество времени, но и получите систему, которая более удобна и удобна. более надежен и дешевле в реализации.
Короче говоря, прекратите попытки изобретать велосипед, потому что ваш текущий дизайн будет больше похож на квадрат с отверстием примерно посередине.
Фактически вы можете создать хорошую среду распределенной базы данных, если вы разделите (или нацелите) свои операции чтения и записи в разные базы данных. Мы делаем такую работу, и все очень просто. У вас есть главная база данных на файловом сервере и нацелены все записи в нее. У вас есть локальная копия базы данных на каждом компьютере пользователя, и вы нацелены на чтение к ней. Теперь вам также понадобится механизм синхронизации между главной базой данных и локальными базами данных. Это можно сделать несколькими способами. Один из способов - иметь дельта-таблицу в базе данных master. Эта дельта-таблица будет содержать транзакции, которые были применены в основной базе данных. Всякий раз, когда приложение пользователя выполняет операцию чтения или записи, дельта на главном устройстве сначала проверяется и обновляется локально. Необходимо применить только еще не примененные транзакции в дельте (которые можно проверить по метке времени). У вас может быть даже непрерывный фоновый процесс. Эта дельта может быть дневной дельтой (или недельной дельтой), когда она сбрасывается. Если пользователь не входил в систему в течение недели или около того, вы просто копируете всю базу данных на компьютер пользователя. Преимущество наличия локальной копии заключается в том, что пользователи могут запрашивать данные, даже когда они находятся в автономном режиме, и - хотите верьте, хотите нет - это довольно быстро, даже когда вы обновляете данные онлайн.
Как уже упоминалось, этот вопрос выходит за рамки системного администрирования. При этом распределенные базы данных и распределенные хранилища данных используются в очень узнаваемых местах. Хотя сильные стороны SQLite обычно не подходят для этого типа приложений, это не является чем-то необычным. Посмотрите, например, на Ископаемое проект. Несмотря на то, что это распределенная система управления исходным кодом, основанная на SQLite, она также предоставляет распределенную вики-страницу и приложение для ведения блога и может действительно помочь вам. Хотя вам, вероятно, следует выйти за рамки SQLite, это не означает, что вам нужно отказываться от открытого исходного кода. Рассмотрите возможность реализации вашего проекта в Apache CouchDB или хранилище данных на основе Hadoop. Еще более новый подход заключается в создании приложений в распределенной виртуальной среде пользовательского пространства, такой как Inferno.
Ваше описание очень похоже на то, что используют системы POS (Point of Sale). При запуске объявляется один главный терминал, который выполняет обработку базы данных. Копия базы данных синхронизируется между главным и всеми подчиненными терминалами для резервного копирования.
Если мастер потерпит неудачу, на всех других терминалах появится сообщение «Сделать меня новым мастером?». Вы нажимаете да, и все продолжается. Это может продолжаться, пока не останется один терминал.
Это работает и является своего рода доказательством идиота, но наличие поврежденной базы данных в конце концов - обычное дело. К счастью, в терминалах хранятся только распродажи в эти дни, поэтому ваши ежедневные итоги могут немного отличаться, поскольку некоторые заказы были сохранены неправильно. Это предпочтительнее, чем система, выходящая из строя на несколько часов и теряющая продажи.
При большом отключении сети / электричества очистка в конце дня - это то, для чего требуется время, поскольку продажи за текущие дни могут распределяться по нескольким различным терминалам, и вам нужно со всем этим разобраться. Я рад, что больше не занимаюсь этой работой.
Придерживайтесь одного большого сервера базы данных с хорошими резервными копиями.
Из вашего вопроса не совсем понятно, где в конечном итоге находятся данные? Он живет на централизованном файловом сервере? В таком случае перемещение ядра базы данных на множество рабочих столов при использовании централизованного файлового сервера в качестве дискового хранилища, вероятно, не принесет вам большой производительности. Во всяком случае, удаленность диска от двигателя, вероятно, приведет к тому, что он будет работать хуже, если вообще будет.
Если данные не централизованы, согласованность данных будет проблемой, если у вас есть несколько рабочих столов, содержащих разные биты данных.
Аналогичные проблемы существуют в отношении конфигурации и безопасности базы данных, ни одна из которых не является тривиальной. И, наконец, запуск сервера базы данных на настольном компьютере, обслуживающем более 100 активных удаленных пользователей, окажет заметное влияние на производительность этого рабочего стола.
Ты видел http://litereplica.io/ ? У них есть драйвер sqlite3 для nodejs, и он кажется довольно хорошо спроектированным.
Недавно я завершил разработку уровня распределенной базы данных для инфраструктуры промежуточного программного обеспечения SOA / ESB / RESTful, которая должна быть проприетарной без использования инфраструктуры базы данных, построенной на C # с оболочкой для SQLite.
Уровень моей базы данных работает как кластер узлов, состоящий из узлов-свидетелей (главный и аварийный), узлов записи / фиксации данных (снова главный и аварийный) и узлов репликации, которые в основном хранят реплицированные данные.
При операциях записи выбранный узел записи генерирует уникальные идентификаторы и внешние ключи, которые индексируются местоположением успешной записи данных в узлы. это гарантирует, что реплицированные данные сохранят те же идентификаторы и внешние ключи. Есть поточные / параллельные процессы, поддерживающие репликацию. Внешние ключи не применяются строго, но работают.
Я также написал клиентскую оболочку для этого уровня данных, которая обеспечивала аварийное переключение строки подключения клиента между свидетелями.
Пока что тестирование и бенчмаркинг, кажется, подтверждают концепцию. Я тестировал данные разного размера, и, похоже, он хорошо справляется. Очевидно, что, поскольку мой уровень базы данных предназначен для промежуточного программного обеспечения Restful, его скорость менее важна, чем высокая доступность. Более того, требования к структуре ваших данных являются основным фактором, определяющим, будет ли этот подход работать или нет.
Моя следующая редакция будет состоять в том, чтобы посмотреть, могу ли я распределять извлечение больших наборов данных по реплицированным узлам, когда набор данных передается в клиентскую структуру, своего рода сетку данных с идеей json.