Было бы неправильно использовать статический объект вместо базы данных?

Question

Это, по сути, вопрос о шаблонах проектирования:

Я ожидал запросить базу данных, чтобы получить список акций (акций / секьюритов), которые наиболее сильно коррелируют для данной акции.

Вместо этого я подумал, что, может быть, мне следует создать объект со статическим HashMap и хранить там свои данные. Затем "запросить" его каждый раз, когда мне нужно.

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

Answer 1

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

Answer 2

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

Однако есть одно предостережение: если объем данных (включая накладные расходы объектов Java и HashMap) становится слишком большим, чтобы полностью удерживаться в оперативной памяти, производительность будет быстро и резко снижаться (в 10 000 и более раз) , Системы баз данных предназначены для эффективного доступа к данным на диске; HashMap нет.

Answer 3

Ваша идея не так уж и плоха, однако я бы лично выбрал решение для кэширования.

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

Answer 4

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

Answer 5

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

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

Одним из вариантов может быть то, что вы храните данные в базе данных, но затем кэшируете их в HashMap.

Answer 6

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

Это приводит к некоторым недостаткам:

• вы не можете делать резервные копии
• вам нужно перекомпилировать / повторно развернуть приложение для изменения данных

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

Answer 7

В этом подходе нет ничего плохого. Просто убедитесь, что у вас нет прямого доступа к статическому классу, потому что тогда вы создаете « bad singleton ». (Как глобальная переменная)

Вместо этого введите какой-нибудь механизм регистрации для регистрации этого класса во всех объектах, которые будут его запрашивать. Чем у вас будет «хороший синглтон» и не будет более поздних выпусков.

public class MyDataClass {
    private MyDataClass() { }
    public static MyDataClass getInstance() {
        if (instance == null) instance = new MyDataClass();
        return instance;
    }
    private static MyDataClass instance = null;
}

public class MyDataProcessor {
    public void registerData(MyDataClass data) { 
       this.data = data;
    }
    public void process() {
        assert(data != null);
        data.getData(...);
    }
    private MyDataClass data;
}

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

Answer 8

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

Все, что вам нужно, это метод сериализации. Я видел, что XStream упоминался выше.

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

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

Answer 9

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

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

Answer 10

Статическое кэширование может работать.

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