Постоянные стратегии состояния базы данных - PullRequest
1 голос
/ 28 февраля 2012

Из-за нескольких правок этот вопрос мог стать немного непоследовательным.Я прошу прощения.

В настоящее время я пишу сервер Python.Он никогда не увидит более 4 активных пользователей, но я студент информатики, так что я все равно планирую это.

В настоящее время я собираюсь реализовать функцию для сохранения резервной копиитекущее состояние всех соответствующих переменных в файлах CSV.Из тех, кого у меня сейчас 10, и они никогда не будут большими, но ... ну, студент-информатик и т. Д.

Итак, я сейчас думаю о двух вещах:

  1. Когда выполнять резервное копирование?
  2. Что за резервное копирование?

Когда запускать:

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

Непосредственно с этим связан вопрос , какое резервное копирование мне следует сделать.

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

Я не могу использовать shelves, потому что я хочу, чтобы данные переносились между различными языками программирования (например, java, вероятно, не может открывать полки python), и я не могу использовать MySQL по разным причинам, главным образом из-за того, чтокомпьютер, на котором будет работать сервер, не поддерживает MySQL, и я не хочу использовать внешний MySQL-сервер, поскольку я хочу, чтобы сервер продолжал работать, когда обрывается интернет-соединение.

Я также осведомлен о фактечто есть несколько способов сделать это с помощью предварительно реализованных функций pYthon и / или другое программное обеспечение (например, sqlite).Я просто большой поклонник создания этого материала не потому, что мне нравится изобретать велосипед, а потому, что мне нравится знать, как работают вещи, которые я использую.Я создаю этот сервер частично только для изучения Python, и хотя знание того, как использовать SQLite, является чем-то полезным, мне также нравится выполнять «грязную работу» самостоятельно.

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

Итак, мой вопрос в основномсводится к следующему: какой метод резервного копирования будет наиболее полезным в этом сценарии, и я, возможно, пропустил другую стратегию резервного копирования?Как вы решаете, какую стратегию использовать в своих приложениях?

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

Ответы [ 2 ]

2 голосов
/ 29 февраля 2012

Использование sqlite . Вы спрашиваете о создании постоянного хранилища с использованием CSV-файлов и о том, как обновлять файлы по мере их изменения. То, что вы просите, - это легкая, переносимая реляционная (как на основе таблиц) база данных. Sqlite идеально подходит для этой ситуации.

Python имеет поддержку sqlite в стандартной библиотеке с версии 2.5 с модулем sqlite3 . Поскольку база данных sqlite реализована в виде одного файла, их легко перемещать по машинам, и у Java есть ряд различных способов взаимодействия с sqlite.

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

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

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

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

Так что, поиграйте с парой разных подходов. Но как только вы захотите, чтобы все работало четко и последовательно, переходите на sqlite.

1 голос
/ 29 февраля 2012

Если ваши данные находятся в файлах CSV, почему бы не использовать систему контроля версий этих файлов? Например. git будет довольно быстрым и даст отличную историю. Репозиторий будет целиком находиться в каталоге, в котором находятся файлы, поэтому с ним довольно легко работать. Вы также можете легко скопировать этот репозиторий на другие машины или каталоги.

...