Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Выбор: OC+СУБД+TimesTen  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
in-memory
Все in-memory, что MySQL-heap, что Timetens при сбое питания потеряют всю инфу из ОЗУ.
Кстати, это тоже полная бредятина. Короче, не рассуждайте о том, чего не знаете.
29 июн 11, 08:57    [10890552]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
svarg
Вот такой пример: в базу валом идут данные с датчиков ~ 900 в сек.
Задача класса XTP
svarg
Как ты эти данные будешь сохранять? Только записывая в память и потом сливая по таймеру партиями одной транзакцией на диск. А если еще необходимо производить расчеты и анализировать каждую! запись, проводит сравнения ... записывать какие нибудь логи работы автоматики...
Например, если приложение на Java, то с помощью Caché eXTreme for Java.
На этом и других подфорумах я приводил примеры кода и результаты.
svarg
Короче ни одна СУБД кроме MySQL (heap) не справляется.
Тройка Диалог
СУБД InterSystems Caché как альтернатива базам данных в оперативной памяти
29 июн 11, 09:34    [10890670]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
servit,

Судя по вакансиям на hh.ru в Тройке используется Sybase, MySQL, MSSQL, Access и много-много-много чего еще. Но ни слова о Cache. В качестве EDA они используют Oracle EDA - а там внутрях есть Oracle CEP и Coherence, который является действительно мощным, отказоустойчивым, in-memory data grid.

Непонятно, нафига им еще и Cache :)

P.S. Как-то странно видеть в банке такой зоопарк.
29 июн 11, 10:19    [10890903]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67426
Блог
Alexander Ryndin
P.S. Как-то странно видеть в банке такой зоопарк.

Он там исторически сложился. На него сетовали и хотели его ликвидировать ещё году в 2005-м, когда меня туда звали. Тогда хотели ползти в сторону MSSQL. Аналогичный бардак был с железом и с операционками - Windows, Solaris, Linux.

По двухмесячной давности рассказу их ИТ-директора, винда как серверная операционка не тянет их нагрузку. С солярисом всё ясно. Как кандидата на основную серверную операционку они рассматривали Ubuntu и Redhat и остановились на Redhat MRG. Соответственно, на лидирующие позиции по СУБД идёт Sybase.
29 июн 11, 14:28    [10893143]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Brodiaga
Member

Откуда:
Сообщений: 501
safety1990
Есть задача (по большей части учебная): ВЫБРАТЬ версии и собрать вместе:
1) Операционную систему (сам отдаю предпочтение Linux, посоветуйте какую именно, вернее какая лучше всего совместима и проверенна вами с выбранными системами).
2) "Стандартную СУБД" (не обязательно последняя 11g, подойдет и 10g, главное чтобы она также была проверенная).
3) СУБД TimesTen (собственно для кэширования отдельных частей БД).


1 - Лучше OEL Update 6.
2 - Тут лучше oracle db ee (думаю версию 11gR2)
3 - 11.2.1.8 - последняя версия TimesTen.

У меня данная конфигурация точно работает. (все имхо конечно).

in-memory
Все in-memory, что MySQL-heap, что Timetens при сбое питания потеряют всю инфу из ОЗУ.


Ну ек-макарек, вы бы хоть почитали бы в начале о продукте, а потом писали.
29 июн 11, 15:06    [10893439]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Timetens
Guest
Brodiaga
in-memory
Все in-memory, что MySQL-heap, что Timetens при сбое питания потеряют всю инфу из ОЗУ.


Ну ек-макарек, вы бы хоть почитали бы в начале о продукте, а потом писали.

Есть два варианта.
1. Транзакция коммитится до сброса данных на диск и тогда при сбое питания данные не сброшенные на диск пропадают.
2. Транзакция коммитится после сброса на диск и тогда скорость при вставке не возрастает, т.к. так же ждет записи на диск.

Собственно в Timetens для хранения используется Oracle. И могут пропасть только данные закомиченные, но не сброшенные из ОЗУ на диск.
29 июн 11, 15:37    [10893728]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Brodiaga
Member

Откуда:
Сообщений: 501
Timetens
Brodiaga
пропущено...


Ну ек-макарек, вы бы хоть почитали бы в начале о продукте, а потом писали.

Есть два варианта.
1. Транзакция коммитится до сброса данных на диск и тогда при сбое питания данные не сброшенные на диск пропадают.
2. Транзакция коммитится после сброса на диск и тогда скорость при вставке не возрастает, т.к. так же ждет записи на диск.

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


Во первых, TimesTen может использоваться как standalone ДБ, так и в связке с Oracle DB EE (или другой базой через XLA).
Конечно, сценарии могут быть разные. В первом случае (1.), запись на диск будет производиться асинхронно, поэтому, часть данных может быть потеряна. При использовании durable commit (случай 2.), данные записываются вместе с транзакцией, поэтому в данном случае, данные НЕ БУДУТ ПОТЕРЯНЫ в случае системного сбоя. Другой вопрос, что при durable commit, может понизиться производительность (это зависит). Но когда я проверял этот фактор (делал правда только insert при надежном коммите и без), пакетные транзакции (по 1000 инсертов например) практически не сказывались на производительность (КОмит после каждого insert, просаживал очень серьезно).

НО, еще есть возможности репликации (особенно ACtive-standby pair), которые позволяют вам сохранить ВСЕ данные в результате различных видов сбоя.

Чудес не бывает, поэтому, нужно подбирать сочетание: производительность - надежность.
29 июн 11, 16:01    [10893982]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
in-memory
Guest
Brodiaga

Во первых, TimesTen может использоваться как standalone ДБ, так и в связке с Oracle DB EE (или другой базой через XLA).
Конечно, сценарии могут быть разные. В первом случае (1.), запись на диск будет производиться асинхронно, поэтому, часть данных может быть потеряна.

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

svarg
Alexander Ryndin
пропущено...
Ню-ню...


Эт не вариант, пробовали уже, считали на MSSQL 2005. Прирост от 0 до 30% ... короче In_memory хоть и в зачаточном состоянии, но без них никуда...

Что-то вы не правильно делали: нехватка CPU или один из файлов tempdb был на HDD. Прирост достигает 10-100 раз.
29 июн 11, 16:16    [10894130]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Brodiaga
Member

Откуда:
Сообщений: 501
[quot in-memory]При этом потеряются данные находящиеся в ОЗУ и не сохраненные на диск, о чем я и говорил.[quot]

Таким образом я могу применить фразу "При этом данные будут потеряны" к ЛЮБОЙ БАЗЕ ДАННЫХ (Oracle DB, MS SQL и др.), т.к. смогу сделать конфигурацию, которая приведет к потере данных.

in-memory
Плюс Timesten как обычно не в том, что тут говорят что он делает что-то чего нельзя без него, а в удобстве использования для хранения в ОЗУ.


Плюс TimesTen - очень маленькое время отклика (микросекунды), высокая пропускная способность и поддержка SQL.
29 июн 11, 17:54    [10895231]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
svarg
Member

Откуда:
Сообщений: 19
Brodiaga
Timetens
пропущено...

Есть два варианта.
1. Транзакция коммитится до сброса данных на диск и тогда при сбое питания данные не сброшенные на диск пропадают.
2. Транзакция коммитится после сброса на диск и тогда скорость при вставке не возрастает, т.к. так же ждет записи на диск.

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


Во первых, TimesTen может использоваться как standalone ДБ, так и в связке с Oracle DB EE (или другой базой через XLA).
Конечно, сценарии могут быть разные. В первом случае (1.), запись на диск будет производиться асинхронно, поэтому, часть данных
...


Brodiaga, если ты спец по Times Ten, можешь просветить, как слинковать ее с MSSQL?
Стандартные ODBC дрова ничем не помогли!
29 июн 11, 18:05    [10895334]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Brodiaga
Member

Откуда:
Сообщений: 501
svarg
Brodiaga
пропущено...


Во первых, TimesTen может использоваться как standalone ДБ, так и в связке с Oracle DB EE (или другой базой через XLA).
Конечно, сценарии могут быть разные. В первом случае (1.), запись на диск будет производиться асинхронно, поэтому, часть данных
...


Brodiaga, если ты спец по Times Ten, можешь просветить, как слинковать ее с MSSQL?
Стандартные ODBC дрова ничем не помогли!


Спец - слишком громко сказано
Что подразумевается под "слинковать"? Если подразумевается возможность создавать кэш группы, то к сожалению, такая возможность есть только в Oracle DB EE.

НO,

Есть возможность реализовать репликацию данных из TimesTen в любую другую базу данных руками (с использованием XLA приложения). Подробней про XLA c примером можно почитать по ссылке http://ggsig.blogspot.com/2011/06/timesten-xla-application.html
Если нужна дополнительная информация пишите в почту.
29 июн 11, 18:31    [10895498]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
in-memory
Guest
Brodiaga
Таким образом я могу применить фразу "При этом данные будут потеряны" к ЛЮБОЙ БАЗЕ ДАННЫХ (Oracle DB, MS SQL и др.), т.к. смогу сделать конфигурацию, которая приведет к потере данных.

И как сконфигурировать Oracle или MS SQL, чтобы потерять закомиченные данные при отключении питания?
29 июн 11, 19:01    [10895651]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67426
Блог
Одному моему знакомому это удавалось. Он говорил, что оракл теряет данные по десять раз на дню, плохо поднимается после сбоев и MySQL гораздо круче. В итоге расследования выяснилось, что он держал базу на дисковом массиве с внутренним непробиваемым кэшем и без упса.
29 июн 11, 19:06    [10895677]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
in-memory
Guest
softwarer
Одному моему знакомому это удавалось. Он говорил, что оракл теряет данные по десять раз на дню, плохо поднимается после сбоев и MySQL гораздо круче. В итоге расследования выяснилось, что он держал базу на дисковом массиве с внутренним непробиваемым кэшем и без упса.

Он конечно молодец :)
Но к конфигурации СУБД это не относится.
29 июн 11, 19:21    [10895717]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
in-memory
И как сконфигурировать Oracle

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

Ну и остается вариант с файлами журнала на RAM диске. :)
29 июн 11, 22:23    [10896087]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Сергей Арсеньев
in-memory
И как сконфигурировать Oracle

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

Ну и остается вариант с файлами журнала на RAM диске. :)
Мне кажется, что журналы и tempdb на RAM-диске - это не поддерживаемые решения - следовательно не рассматриваются, если вы, конечно, не научный работник в области СУБД.
29 июн 11, 22:30    [10896107]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
сброса буфера журнала
Guest
Сергей Арсеньев
in-memory
И как сконфигурировать Oracle

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

Т.е. в биллинговой системе человек положил себе деньги на счет, свет моргнул, деньги отдал, а на счет они не поступили?
29 июн 11, 22:40    [10896137]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
сброса буфера журнала
Т.е. в биллинговой системе человек положил себе деньги на счет, свет моргнул, деньги отдал, а на счет они не поступили?

Ну да, если сам попросил, делай что хочешь побыстрее возьми деньги. :)
Естественно в ситуации когда данные о зафиксированных транзакциях приоритетнее скорости фиксации транзакции такое решение не применяется. Но в системах, где данные за последние два часа вроде бы никого не канают почему бы не использовать. :)
29 июн 11, 22:44    [10896149]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
сброса буфера журнала
Guest
Сергей Арсеньев
сброса буфера журнала
Т.е. в биллинговой системе человек положил себе деньги на счет, свет моргнул, деньги отдал, а на счет они не поступили?

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

А TimesTen во сколько раз выигрывает у такой конфигурации с незбрасываемыми буферами при равной аппаратной части?
29 июн 11, 23:00    [10896190]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
in-memory
svarg
пропущено...


Есть большая разница, иначе бы хрен Oracle купил times ten.
Вот такой пример: в базу валом идут данные с датчиков ~ 900 в сек. Как ты эти данные будешь сохранять? Только записывая в память и потом сливая по таймеру партиями одной транзакцией на диск. А если еще необходимо производить расчеты и анализировать каждую! запись, проводит сравнения ... записывать какие нибудь логи работы автоматики...
Короче ни одна СУБД кроме MySQL (heap) не справляется. Oracle+timesten пока к сожалению не купили. Если кто работал в times ten - прошу поделиться впечатлениями.

Все in-memory, что MySQL-heap, что Timetens при сбое питания потеряют всю инфу из ОЗУ.
Такого же эффекта можно добиться положив tempdb от любой СУБД на RAMDisk. Пиши в неё, а затем в основную БД.


Феерично
30 июн 11, 09:23    [10896990]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
сброса буфера журнала,

Ну вот к примеру
30 июн 11, 09:25    [10896999]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Timetens
Собственно в Timetens для хранения используется Oracle. И могут пропасть только данные закомиченные, но не сброшенные из ОЗУ на диск.


И вновь бред. TimesTen использует собственное журналирование, а также сбрасывает грязные данные на диск в свое перманентное хранилище ну и, конечно, может реплицировать изменения, например в Oracle. Разумеется все это Durability можно отключить, но ... тут выбор за вами.

В общем иногда лучше почитать чем продолжать нести бред
30 июн 11, 09:28    [10897010]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
С солярисом всё ясно.

а что не так с солярисом? ведь solaris better linux than linux?
1 июл 11, 09:49    [10904252]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67426
Блог
ScareCrow
автор
С солярисом всё ясно.

а что не так с солярисом? ведь solaris better linux than linux?

Он умер. А так с ним всё в порядке, конечно.
1 июл 11, 12:54    [10905553]     Ответить | Цитировать Сообщить модератору
 Re: Выбор: OC+СУБД+TimesTen  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
softwarer
ScareCrow
пропущено...

а что не так с солярисом? ведь solaris better linux than linux?

Он умер. А так с ним всё в порядке, конечно.
А мужики то и не знают (c)
1 июл 11, 13:06    [10905683]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить