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 при сбое питания потеряют всю инфу из ОЗУ.

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

TimetensBrodiagaпропущено...


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

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

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

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

Чудес не бывает, поэтому, нужно подбирать сочетание: производительность - надежность.

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

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

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

Плюс TimesTen - очень маленькое время отклика (микросекунды), высокая пропускная способность и поддержка SQL.

svargBrodiagaпропущено...


Во первых, 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
Если нужна дополнительная информация пишите в почту.