|
|
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Добрый день, господа. Нужно выбрать СУБД для высоконагруженной OLTP системы. Характер нагрузки - в основном update и select. Пользователей - около 5000. Объёмы порядка нескольких гигабайт. Может быть десятков гигабайт. Подключаться будут они не напрямую а через промежуточный слой, но тем не менее :) Дополнительное ограничение - цена. Первым делом рассматриваются бесплатные и урезанные версии платных субд :) Полный список хотелок. Возможность горячего бэкапа Версионник. Полноценные транзакции и ограничения целостности. Возможность создания кластера Возможности оптимизации хранения данных (partitioning, IOT и тп). Способность работать с тысячей коннектов (shared server?) Поддержка 64 разрядной ОС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 17:51 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpПользователей - около 5000.Одновременно или всего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 17:53 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp Первым делом рассматриваются бесплатные и урезанные версии платных субд :) Firebird. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 17:54 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov oltp Первым делом рассматриваются бесплатные и урезанные версии платных субд :) Firebird.Не подойдет. Автору треба авторВозможности оптимизации хранения данных (partitioning, IOT и тп). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 17:58 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoft, Логически одновременно. 5000 клиентов будут достаточно быстро долбить update-select-ы с некоторыми паузами между ними. Часть нагрузки мы наверное сможем снять промежуточным сервером.. Ну допустим порядка 300 update-ов в секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 17:59 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Неточно выразился. Не 300 update-ов мы снимем, а 300 update-ов оставим :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:01 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpmiksoft, Логически одновременно. 5000 клиентов будут достаточно быстро долбить update-select-ы с некоторыми паузами между ними. Часть нагрузки мы наверное сможем снять промежуточным сервером.. Ну допустим порядка 300 update-ов в секунду.Именно update-ов? Можно поподробнее о характере нагрузки? Терзают меня смутные сомнения, что правильно примененная буферизация может снизить требования на порядок-два. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:04 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoftoltpmiksoft, Логически одновременно. 5000 клиентов будут достаточно быстро долбить update-select-ы с некоторыми паузами между ними. Часть нагрузки мы наверное сможем снять промежуточным сервером.. Ну допустим порядка 300 update-ов в секунду.Именно update-ов? Можно поподробнее о характере нагрузки? Терзают меня смутные сомнения, что правильно примененная буферизация может снизить требования на порядок-два. Именно update-ов. У 5000 датчиков есть параметры которые они меняют раз в секунду. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec. Если изменить update на инсерт последнего состояния, то через некоторое время быстро сделать select для определения последнего состояния будет невозможно, да и база вырастет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:09 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpУ 5000 датчиков есть параметры которые они меняют раз в секунду. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec.Во-первых, получается 5000 update-ов в 10 секунд, что несколько не то же самое. Во-вторых, у меня напрашивается другое решение. Раз в 10 секунд делать табличке truncate и грузить загрузчиком (а не INSERT-ами) туда данные. Думаю, в секунду уложитесь даже на десктопном железе. Кстати, и как отсюда вытекают "Объёмы порядка нескольких гигабайт"? Или это какие-то другие объемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:15 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Senya_LАвтору треба На его-то нагрузку? Не смешите мои подковы! oltp Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec. Это неправильное решение. В особенности для версионников. Последнее состояние датчиков лучше держать в промежуточном слое, а в базу сбрасывать только суммарные данные для отчётов, тарификации (или что там у вас). Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:17 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
обычно датчики пишут в файл, а уже из файла раз в какое-то время выгружают в БД, где уже анализируют данные ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:24 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoftoltpУ 5000 датчиков есть параметры которые они меняют раз в секунду. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec.Во-первых, получается 5000 update-ов в 10 секунд, что несколько не то же самое. Согласен. miksoftВо-вторых, у меня напрашивается другое решение. Раз в 10 секунд делать табличке truncate и грузить загрузчиком (а не INSERT-ами) туда данные. Думаю, в секунду уложитесь даже на десктопном железе. Надо подумать. Но на вскидку.. Делаем truncate и электричество выключается. ППЦ. Другие хинты вроде двух таблиц и переименований будут делать блокировку всех данных таблицы, пока переименование не закончиться. В эту таблицу могут писать и из неё могут читать и другие. Блочить всех раз в 10 секунд, пусть и на полсекунды.. в нашем случае это неприемлимо. Но мысль понятна, буду думать. miksoftКстати, и как отсюда вытекают "Объёмы порядка нескольких гигабайт"? Или это какие-то другие объемы? Это другие объёмы. Я описал отчего происходит основная нагрузка. Все остальные варианты использования вместе взятые генерят ещё примерно половину от этой нагрузки + большую часть данных. Обсуждение снижения нагрузки, это конечно хорошо, но хотелось бы всё-таки вернуться к обсуждению субд. Что, в контексте моей проблемы, народ скажет про "основных игроков" postgresql и mysql ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:26 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Yo.!обычно датчики пишут в файл, а уже из файла раз в какое-то время выгружают в БД, где уже анализируют данные ... Это хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:28 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Senya_LАвтору треба На его-то нагрузку? Не смешите мои подковы! Требуется очень маленькое время отклика. Я готов партиционировать даже табличку в 1000 строк, если это поможет. А это может помочь :) Да и полный характер нагрузки я не знаю, постановка задачи ещё не закончена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:30 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp Это хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются. ну и нах тогда в базу что-то писать ? субд тут каким боком ? или масив на 5000 элементов в памяти у вас не помещается ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:32 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Yo.!oltp Это хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются. ну и нах тогда в базу что-то писать ? субд тут каким боком ? или масив на 5000 элементов в памяти у вас не помещается ?? Дубль два. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:34 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpДелаем truncate и электричество выключается. ППЦ.Если "электричество выключается", то не все ли равно - не получат клиенты пустую табличку или они не получат данные с датчиков? Они же все равно ничего не получат... oltpОбсуждение снижения нагрузки, это конечно хорошо, но хотелось бы всё-таки вернуться к обсуждению субд. Что, в контексте моей проблемы, народ скажет про "основных игроков" postgresql и mysql ?Неправильным проектированием загубить можно БД на любой СУБД. MySQL хорош тем, что у него есть движок для хранения данных только в памяти. Т.е. загрузка данных может быть сведена вообще до миллисекунд. Но этот движок не транзакционен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:37 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp Дубль два. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. не вьезжаю. для реалтайма есть масив в памяти (снимать данные нуна в память как не крути), для БД пишутся файлы. в чем смысл чего-то терять ? если комп вырубается когда он поднимится всегда есть возможность из файлов в БД загрузить последние записанные в файлик данные ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:40 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpYo.!oltpЭто хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются.ну и нах тогда в базу что-то писать ? субд тут каким боком ? или масив на 5000 элементов в памяти у вас не помещается ??Дубль два. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд.Назовите этот массив термином "база". Полушутка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:40 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp Я готов партиционировать даже табличку в 1000 строк, если это поможет. А это может помочь :) Мнда... Я передумал: ни в коем случае не ходи в сторону Firebird, оставайся на Oracle. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:42 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoftoltpДелаем truncate и электричество выключается. ППЦ.Если "электричество выключается", то не все ли равно - не получат клиенты пустую табличку или они не получат данные с датчиков? Они же все равно ничего не получат... Дубль три. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. oltpНеправильным проектированием загубить можно БД на любой СУБД. MySQL хорош тем, что у него есть движок для хранения данных только в памяти. Т.е. загрузка данных может быть сведена вообще до миллисекунд. Но этот движок не транзакционен. Над in memory database я подумаю, спасибо за напоминание. Непонятно только , обеспечивает ли она сохранение данных при выключении электричества :) Если не обеспечивает - нужна ещё одна, для постоянных данных. Всем: НЕ ЗАМОРАЧИВАЙТЕСЬ НА ДАТЧИКАХ . Кроме этого в БД есть ещё много всего. Не пытайтесь оптимизировать нагрузку, я создам соответствующий тред, если сам не справлюсь. Даже если убрать датчики нафиг, мои требования изложенные в первом посте всё ещё актуальны. Посоветуйте лучше что-нибудь по первому вопросу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:44 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpmiksoftoltpДелаем truncate и электричество выключается. ППЦ.Если "электричество выключается", то не все ли равно - не получат клиенты пустую табличку или они не получат данные с датчиков? Они же все равно ничего не получат...Дубль три. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. К базе на выключенном сервере это тоже относится??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:48 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpКроме этого в БД есть ещё много всего. Не пытайтесь оптимизировать нагрузку, я создам соответствующий тред, если сам не справлюсь. Даже если убрать датчики нафиг, мои требования изложенные в первом посте всё ещё актуальны. Посоветуйте лучше что-нибудь по первому вопросу.А про это вы ничего, кроме общих слов, не сказали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:49 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoft, Аксиома :) Если система упадёт, упадёт она вся. Промежуточный слой тоже. Клиенты принудительно отключаются. Требование - При включении после краша, данные в системе должны отставать не более чем на 10 секунд от предкрашевого состояния. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:52 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
miksoftА про это вы ничего, кроме общих слов, не сказали. Потому что пока не могу, т.к. большая часть идей ещё в разработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:54 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
> Автор: oltp > Требование - При включении после краша, данные в системе должны отставать не более чем на 10 секунд от > предкрашевого состояния. И чем мешает файлик с последними данными, даже если сервер с базой упал, файлик фсе равно писатся будет, останется просто накатить то чего не в БД после подъема. Т.о. данные в БД будут отставать от реальных только если упадут датчики Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:57 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpТребование - При включении после краша, данные в системе должны отставать не более чем на 10 секунд от предкрашевого состояния.А смысл? Не лучше ли при включении сразу же произвести загрузку новых показаний? Тем более, что время загрузки несравнимо меньше времени старта любого сервера+СУБД, особенно после аварийного останова. Но если очень хочется, то замените truncate на delete. Так медленнее, но зато транзакционнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:57 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp Требование - При включении после краша, данные в системе должны отставать не более чем на 10 секунд от предкрашевого состояния. В сочетании со словами "Надо в базе всегда держать последнее состояние параметров" звучит как полный бред. Уже через секунду после рестарта системы, датчики обеспечат её абсолютно свежими данными. Останется ещё 9 секунд на покурить. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 18:59 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Ну и финальный штрих :) Начальное состояние датчиков после рестарта - важно. Поэтому их надо хранить). Повторю ещё раз - забудьте про них. СУБД лучше посоветуйте) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 19:07 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpНу и финальный штрих :) Начальное состояние датчиков после рестарта - важно. Поэтому их надо хранить).Включите загрузку новых данных в процеду рестарта и хранить будет не надо. oltpПовторю ещё раз - забудьте про них. СУБД лучше посоветуйте)Список СУБД, которые точно подходят под ваши требования, слишком узок, чтобы сред них нашлась хоть одна, о которой вы не знаете. И, одновременно, список ваших требований вызывает такие сомнения, что советовать что-то конкретное бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2009, 19:21 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Нагрузка, честно говоря, детская, так что основная задача - это обеспечить HA на кластере. Так как допустима задержка в 10 секунд, то вполне допустимо даже обеспечение HA через репликацию (хотя, конечно, logshipping лучше). Про бесплатные базы - не скажу, хотя, подозреваю, приделать к MySQL какой-нибудь heartbeat для переключения мастера в репликации - вполне возможно. Для DB2 Express C есть tutorial для реализации logshipping "ручками" (хотя админу и придется постараться). Ну или купить с годовой поддержкой HADR, оно может и дешевле оказаться (3K). Если applayer на java, то можно посмотреть в сторону cjdbc (clustered jdbc). На таких нагрузках - вполне. Да, еще можно поиграть с insert изменений (вместо update) и асинхронной "сборкой" последнего значения (например, каждые 100 записей). Это уменьшит число update в сто раз :) И ничего не потеряется, и скорость будет более, чем достаточная даже на блокировочнике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2009, 01:08 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
DPH3 подозреваю, приделать к MySQL какой-нибудь heartbeat для переключения мастера в репликации - вполне возможно. Эта софтина называется MMM. Переключает мастеров по мере гибели. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2009, 01:49 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltp, не радиорелейка случайно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2009, 19:25 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
Предлагаю решение для DB2, более-менее подобное можно сделать на любой системе. 1. Создать программный сервер, аккумулирующий показатели датчиков в памяти в банальном массиве (ассоциативном?). Все датчики будут писать в него, только он будет писать в БД на том же сервере локальным коннектом (т.е. фактически память-память). Все асинхронно, взаимных блокировок в памяти нет, т.к. все пишут - он читает. 5000 пользователей превращаются в 1-го 2. В БД создать временную таблицу без логирования, в которую оно и будет писаться. Можно и одним оператором (типа merge с массивом), можно кучей - все равно, т.к. из этой таблицы никто не читает. Для DB2 можно использовать range clastered index, для остальных можно rowid (в Oracle вроде есть hash-индексы) 3. По окончании записи - одной командой merge занести все из временной в постоянную таблицу, которая тоже с range clastered index или rowid, но его с осторожностью :). 2-3 повторять как угодно часто - операция на локальном коннекте займет крайне мало времени, все записи гарантированно в кеше, за счет одного запроса в log лишнее не запишется. Оптимально даже для блокировочника - блокировка основной таблицы очень непродолжительна. Да, логи надо класть на отдельное быстрое устройство. Таким образом для DB2: oltpНужно выбрать СУБД для высоконагруженной OLTP системы. Пользователей - около 5000. Объёмы порядка нескольких гигабайт. Может быть десятков гигабайт. Подключаться будут они не напрямую а через промежуточный слой, но тем не менее :) Дополнительное ограничение - цена. Первым делом рассматриваются бесплатные и урезанные версии платных субд :)Система не очень нагружена, пользователей гораздо меньше :) Объемы небольшие, так что м.б. подойдет и бесплатная, например DB2 Express-C. Остальные урезанные версии платных видимо не подойдут - там до 4Гб размер БД. oltp1.Возможность горячего бэкапа 2.Версионник. 3.Полноценные транзакции и ограничения целостности. 4.Возможность создания кластера 5.Возможности оптимизации хранения данных (partitioning, IOT и тп). 6.Способность работать с тысячей коннектов (shared server?) 7.Поддержка 64 разрядной ОС.1. есть 2. Только для уровня CS. В большинстве случаев достаточно. Впрочем, учитываяoltpЭто хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются.и частоту их опроса, версионник Вам м.б. не очень-то полезен, или я чего в задаче не понимаю. 3. есть 4. высоконадежного? Есть в платной, и куда дешевле остальных платных. Как уже говорили, "теплый" при желании можно и на бесплатной версии сделать. 5. 0_0 Это зачем? На неск. гигабайтах и 1000 юзеров?! Есть, конечно, но как и у всех за большие деньги. Для оптимизации кластерных индексов Вам более чем хватит. 6. Даже бесплатный может справиться. Тем более что через сервер приложений 1000 легко превратиться в 300 или меньше в пуле коннектов. 7. есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2009, 19:35 |
|
||
|
Бесплатный OLTP кластер.
|
|||
|---|---|---|---|
|
#18+
oltpДобрый день, господа. Нужно выбрать СУБД для высоконагруженной OLTP системы. Характер нагрузки - в основном update и select. Пользователей - около 5000. Объёмы порядка нескольких гигабайт. Может быть десятков гигабайт. Подключаться будут они не напрямую а через промежуточный слой, но тем не менее :) Дополнительное ограничение - цена. Первым делом рассматриваются бесплатные и урезанные версии платных субд :) Полный список хотелок. Возможность горячего бэкапа Версионник. Полноценные транзакции и ограничения целостности. Возможность создания кластера Возможности оптимизации хранения данных (partitioning, IOT и тп). Способность работать с тысячей коннектов (shared server?) Поддержка 64 разрядной ОС. http://sourceforge.net/projects/opendsa/ 1. платный плагин, база и журналы. 2. Без рестарта транзакций, ядро блокировчник, платный плагин для тех кто без нее жить версионности не может. ( дополнительный уровень изолированости). 3. полнолное соответствие SQL92. 4. Платный плагин shared nothing cluster. 5. Есть , в плоть до разбрасывания партиций по серверам кластера. 6. Невытесняющая многозадачность , ядро само переключает контектсты выполнения пользовательский сессий. Количество процессов (нитей) в ОС стремится к количеству процессоров. и не зависит от количества активных пользователей. Общий пул памяти для сортировок всех сессий, сортировки уходят в темпДБ только после заполнения пула. 7. Linux , AIX портирование под MS автором не планируется. 8. Автором планируется внедрение PHP в качестве основного языка програмирования процедур. Плагины PL/SQL T-SQL будут разрабатываться после выходя первой версии мотора СУБД и будут платными. oltpПотому что пока не могу, т.к. большая часть идей ещё в разработке. Аналогично , разработка ведется одним человеком в свободное от основной работы время. Говность около 20 -30 % ( ~20 000 строк кода). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2009, 21:33 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1552887]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 11ms |
| total: | 182ms |

| 0 / 0 |
