|
Производительность и транзакции в Cache и GlobalsDb (java globals API)
|
|||
---|---|---|---|
#18+
Добрый день. Пишу приложение, работающее с обеими СУБД с использованием java globals API ( http://docs.intersystems.com/cache20131/csp/docbook/DocBook.UI.Page.cls?KEY=BXJV_globals#BXJV_globals_transact_transact ). У меня есть два потока выполняющих вставку данных. До данного момента вставлял данные с помощью connection.createNodeReference и далее node.appendSubscript и node.set. Насколько тяжеловесна операция createNodeReference? Могу ли я для вставки новой записи каждый раз ее вызывать? И я так понимаю, что данные на диск записываются после вызова node.close, это так? Дело в том, что мой код мог отработать, я даже закрыл программу, а диск может еще скрипеть секунд двадцать. Что в этот момент происходит? Фактически приложение выполняет массовую вставку записей постоянно. В реляционных СУБД при вставке большого количества записей важно делать это пачками в рамках одной транзакции (например, одна транзакция на 1000 вставок). С java globals API та же ситуация? Если да, то как запускать разные транзакции из разных потоков? Судя по документации соединение разделяется между потоками. И еще вопрос. Есть ли серьезная деградация производительности вставки при накоплении в одном из узлов нескольких сотен тысяч или миллионов узлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2014, 18:31 |
|
Производительность и транзакции в Cache и GlobalsDb (java globals API)
|
|||
---|---|---|---|
#18+
TryCacheНасколько тяжеловесна операция createNodeReference? Могу ли я для вставки новой записи каждый раз ее вызывать?Если данные вставляются в один и тот же глобал, но в разные подиндексы, то, конечно, не сто́ит: разработчики ведь не зря разделили эти методы (createNodeReference, appendSubscript, setSubscript, set, ...). К тому же при прочих равных, голые ссылки немного быстрее полных: Naked Global Reference . TryCacheИ я так понимаю, что данные на диск записываются после вызова node.close, это так?Нет, не так. И это легко проверить: достаточно сразу после set поставить задержку и посмотреть в БД или вовсе убрать вызов node.close. TryCacheДело в том, что мой код мог отработать, я даже закрыл программу, а диск может еще скрипеть секунд двадцать. Что в этот момент происходит? Two-Phase Write Protocol TryCacheФактически приложение выполняет массовую вставку записей постоянно . В реляционных СУБД при вставке большого количества записей важно делать это пачками в рамках одной транзакции (например, одна транзакция на 1000 вставок). С java globals API та же ситуация?Нет, Caché ведь не реляционная СУБД, а потому лишена этих "ограничений". К тому же при постоянной вставке (наверное, имелось в виду непрерывно?) лучше использовать одну транзакцию на запись (по умолчанию), иначе в случае отката есть риск потерять гораздо более чем одну записей. TryCacheкак запускать разные транзакции из разных потоков? Судя по документации соединение разделяется между потоками.Документация: Considerations for Safe ThreadingThe single Connection instance may be used safely in multiple threads with these caveats: источник Ничего не мешает использовать свой собственный Connection в каждом потоке, предварительно указав Код: java 1.
TryCacheИ еще вопрос. Есть ли серьезная деградация производительности вставки при накоплении в одном из узлов нескольких сотен тысяч или миллионов узлов?Нет, потому и выбирают MUMPS (GT.M, MiniM, Caché, ...). К тому же это является стандартной схемой хранения данных для таблиц/классов в Caché. Вы можете хранить вообще все Ваши данные в одном/двух глобалах и примеры тому были. Затык может возникнуть в железе, в объёме данных, но это уже уровень Enterprise, для которого существуют ECP , Global Mappings (отображение части данных на разные бд/диски/сервера) ... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2014, 11:23 |
|
|
start [/forum/topic.php?fid=39&gotonew=1&tid=1556748]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
8ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 274ms |
total: | 404ms |
0 / 0 |