pkarklinAlexander RyndinКак минимум в 10g это было . Думаю еще и раньше.

А в связке с in-memory tables? Сам по себе машинный код не нужен, если основные затыки будут на IO.Че вам так эти in-memory таблицы дались? При достаточно прогретом кэше таблицы и так in-memory, а ваши in-memory таблицы имеют кучу ограничений.

pkarklinAlexander RyndinЧе вам так эти in-memory таблицы дались? При достаточно прогретом кэше таблицы и так in-memory, а ваши in-memory таблицы имеют кучу ограничений.

А, вдруг, лучшее будет, ну, скажем не 1 мс, а 1 мкс время отклика? Для 10ков тысяч запросов в сек.Не будет. У сети задержки больше. Да и не нужно это 99,9% пользователей. А тем, кому нужно у Oracle успешно используют тот же TimesTen или Coherence. Вот там за счет отсутствия tcp/ip достижимы скорости, близкие к 1 мкс.

user1cAlexander RyndinЧе вам так эти in-memory таблицы дались? При достаточно прогретом кэше таблицы и так in-memory, а ваши in-memory таблицы имеют кучу ограничений.Это да, но даже с прогретым кешем мы все равно упираемся в latch и locks. Именно тут (по задумке создателей) гекатон должен облегчить всем жизнь.ну это вы, наверное, на mssql упираетесь в 'латчи и локи'. На правильно настроенном оракл мы упмраемся в процессор или ввод-вывод. Чтобы не упмраться во ввод-вывод нужно всего лишь отключить сброс кэша по commit. Вот только тогда вы теряете ACID, что для большинства серьёзных компаний неприемлемо

softwareruser1cНе понял, поясните пожалуйста.
Александр, видимо, имеет в виду вот это . То есть возможность ускорить коммит ценой возможности потерять при отказе последние закоммиченные транзакции.Возможность ослаблять требование ACID (в плане durability) существует уже 100 лет. Тот же TimesTen или Oracle NoSQL позволяют разрешить СУБД не гарантировать запись транзакции на диск при ее фиксации. Вот только нужно четко осознавать последствия потери транзакций. И вся логика приложения должна строиться, исходя из того, чтобы СУБД ненадежна