|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Подскажите шаги по улучшению работы конвертации справочных значений. Требования: высокая нагрузка, минимальное время конвертации. Что имеется сейчас и как реализовано: БД Oracle с таблицей: Код: plsql 1. 2. 3. 4. 5. 6. 7.
Код: plsql 1. 2. 3. 4. 5. 6. 7.
Таких строк будем считать более 10к, и возможно добавление и изменение значений. При преобразованиях указывается нужные параметры для получения нового значения: Код: plsql 1.
Запросы выполняются из Java сервиса, по чистому JDBC без ORM прослоек. Интересует: Как можно ускорить преобразование справочных значений? - Наверняка надо кэшировать в памяти, размер кэша предполагаю "не большой". Если кэш - то как синхронизировать значения кэша с тем хранилищем, где хранятся значения справочника? По времени сбрасывать весь кэш или как-то отслеживать время изменения перед преобразованием (но это потенциальная задержка каждого преобразования) Будут ли плюсы от использования NoSQL БД? Может быть есть какие-то готовые opensource продукты для работы со справочниками? Какие есть варианты или предположения: 1. Настроить на Oracle хранение таблицы в памяти или какое-то другое кэширование запросов. минус - запросы по сети и потеря время на этом. 2. Перейти на Postgres (Oracle излишний для этой задачи) и тоже настроить кэширование данных БД. минус - запросы по сети и потеря время на этом. плюс - не нужна лицензия за БД. 3. Использовать какие-то БД типа "ключ-значение" - тут пока пробел. Ключом тогда будет составное значение sys_from + sys_to + code_from + dict_name Будет ли это быстрее чем использование реляционных БД? Готов ответить на ваши вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 17:48 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Не очень понятно что именно тормозит. Нужны данные профилирования Java приложения. Это как сделать томограмму больному. Понимаешь да? Иначе мы судим не ботлнек а просто твои мысли на эту тему. Вобще. Если это оракл то у тебя должны быть проиндексированы следующие поля Код: plsql 1.
+опции сжатия индекса надо попробовать потом оционально. Еще есть второй вариант - перестроить табличку в индексно-организованную. Но ты попробуй сначала первый вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:01 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий, Если честно не совсем понял задачу... Но понял одно...надо какие-то преобразования над данными. И тут лучше всего подойдёт Пакетные или хранимые процедуры Oracle(pl/sql или Postres (pl/pgsql) Но то если вы можуту изменять код приложения... Вместо Код: plsql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:06 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Будут ли плюсы от использования NoSQL БД? В общем случае нет. Пока не будет идентифицирован проблемный кусок кода. Если например проблема - сетевая интеракция (медленно летают TCP) пакеты от вашего сервера приложений из Череповца в Чикаго - то хоть какую БД ставь - все равно будет плохо и нудно. Поэтому и нужно точно-точно понять какая java-строка работает медленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:16 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий, Это - code_to как потом используется? Если результат конвертации записывается в БД, тогда делайте все в пакетной процедуре в БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:24 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий, Никто не понял задачи. И я тоже. Конвертировать справочник надо одноразово. Зачем тут скорость? При конвертации все работы встают. То есть ночью. Зачем тут скорость? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:33 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Про томограмму понимаю :-) Хочется иметь "кэш" этих данных в самом сервисе, чтобы избежать запросов по сети в БД. Или может быть какую-то inmemory БД поднимать в сервисе и туда переливать данные из реляционной БД, т.к. inmemory поиска кажется будет быстрее. Вопрос больше сводиться к тому как правильно построить кэш который будет наполняться значениям из БД. Как следить за актуальность кэша, как выбрать ключ, если использовать БД типа "ключ-значение", Подойдёт ли тут Redis? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:39 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий, По тексту видно что прогер сам себе ищет работу. Почему справочник надо кешировать, а журнал документов нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:48 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Бред какой-то. От начала и до конца. Описываемая задача является стандартной для любой СУБД. Называется .... JOIN Зачем сервис, Java, кэш, Redis или что нибудь другое - вообще не понятно ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:48 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий Вопрос больше сводиться к тому ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:48 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, +1))) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:49 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий Про томограмму понимаю :-) Хочется иметь "кэш" этих данных в самом сервисе, чтобы избежать запросов по сети в БД. Или может быть какую-то inmemory БД поднимать в сервисе и туда переливать данные из реляционной БД, т.к. inmemory поиска кажется будет быстрее. Вопрос больше сводиться к тому как правильно построить кэш который будет наполняться значениям из БД. Как следить за актуальность кэша, как выбрать ключ, если использовать БД типа "ключ-значение", Подойдёт ли тут Redis? Очень многие вещи в архитектурах создаются итеративно. Тоесть ты ищещь решение. Пробуешь. Плохо? Изменяешь. Наперед никакой архитектор здесь и в прочих форумах тебе никогда не посоветует решение чтоб на всегда. Редис тоже имеет недостатки вида ограниченность памяти и неизвестность сколько TTL ставить на каждую запись. Понимаешь да? Это как транспортная задача. Задача со многими неизвестными. В качестве inmemory dbms я навскидку вспоминаю: Java: Hazelcast, Ignite, Oracle Koherence, Cassandra. Native: Redis, Memcached. Кстати подумай о том как твой кеш будет инвалидироваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 18:53 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
предлагаю автора в бан,кто за ,кто воздержался ?) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:08 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
apb12, )) ТС, Какой из трех вопросов потерял актуальность: - как конвертить спавочник - как кешировать справочник - no sql бд лучше ли оракла для моего проекта ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:11 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
PetroNotC Sharp apb12, )) ТС, Какой из трех вопросов потерял актуальность: - как конвертить спавочник - как кешировать справочник - no sql бд лучше ли оракла для моего проекта ? его вопрос потерял актуальность вот с этой фразой "Запросы выполняются из Java сервиса, по чистому JDBC без ORM прослоек." за это нужно бить палками на площадях,потому что потом их говнокод будут разбирать такие как и проклинать свою жизнь))) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:22 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Мы тоже не используем ORM. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:29 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
apb12, Согласен. Но вдруг у него внешний заказчик с этим сервисом сидит. Тогда там другие законы. Законы а ля soap. Или твой сервис))) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:31 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
mayton Мы тоже не используем ORM. Зато у оракла кеш есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:32 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mayton Мы тоже не используем ORM. Зато у оракла кеш есть. TimesTen? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 19:59 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
mayton, нет. Из коробки) Database caches какие в базах данных есть кэши: Buffer cache — кэш данных — cache for data pages/data blocks; Statement cache — кэш операторов и их планов — cache of queries plan; Result cache — кэш результатов строк — rows from queries; OS cache — кэш операционной системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 20:11 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
У всех dbms это есть. Но топик не об этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 22:03 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
mayton, Да. Ты выше замечательно сказал - итеративный подход. Его нет у автора. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2019, 22:48 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
apb12 предлагаю автора в бан,кто за ,кто воздержался ?) Предлагаю тебя в бан. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2019, 05:20 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
apb12 за это нужно бить палками на площадях,потому что потом их говнокод будут разбирать такие как и проклинать свою жизнь))) Вот прям сейчас разбираю говнокод с орм там, где он не нужен. А вообще с твоей компетенцией и так уже всё ясно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2019, 05:21 |
|
Работа с преобразованием справочников из Java
|
|||
---|---|---|---|
#18+
Морфий, 10к записей - это ни о чём. Даже миллион таких записей ява прожуёт на обычном компе. Можешь всё выбрать и разложить по HashMap/TreeMap/поисковым деревьям или тупо по комплексному ключу. Бд тут вообще не при чём, не трогай её, ты дольше ходить будешь по сети. С инвалидацией кэша - не знаю, как у тебя данные обновляются, ничего не могу сказать. Если всё идёт через яву, прям там и синхронизируй всё, вообще никаких проблем. Морфий Готов ответить на ваши вопросы. Какая нагрузка на сервис в запросах/сек? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2019, 05:29 |
|
|
start [/forum/topic.php?fid=59&msg=39905144&tid=2120977]: |
0ms |
get settings: |
19ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
41ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
444ms |
get tp. blocked users: |
0ms |
others: | 296ms |
total: | 812ms |
0 / 0 |