DPH3Выигрыш можно получить, если делать как в некоторых noSQL базах - на диск писать потоком список операций
Вы не поверите! Но в каше очень хорошо видно, как SQL распадается на микрооперации, и эти микрооперации пишутся потоком в журнал. И эти микрооперации как раз можно проводить самостоятельно.

Физику не обманешь, значит скорость всех субд зависит только от физики?
Но это не так. Очень много производительности теряется на сопутствующих операциях, причем из-за высокого уровня абстракции и закрытости субд тяжело понять, что именно происходит.

80000/с это не скорость записи в базу. Это скорость передачи с внешним приложениям.
Если я не ошибаюсь, это именно была скорость единичного обмена.
Внутренняя скорость чтения и записи зависит от скорости диска, тут все гораздо проще.

Ну как вам на примере показать...

Есть бейсик для 1С. Где вроде как и есть какие-то объекты и какие-то операции, но на самом деле непонятно, как оно все это делает и почему тормозит. Теоретически, конечно, оно может работать и оптимально, а на практике не очень, и никакая физика не помогает

И есть объектно-ориентированный ассемблер (типа С++), и предположим, что он имеет альтернативные объекты и объекты.

an0nymБлок А.Н.,

короче. Если я в середине вашего теста выдерну UPS и сетевое питание - запишется ничего, часть или база будет в corrupted состоянии и самостоятельно уже не поднимется?

В журнал пишутся атомарные операции(в основном, set и kill), а не операции с объектами или sql.
1.Журнала два, операционный и постоянный, в базу данные записываются данные после записи в операционный журнал. В какой момент данные записываются в постоянный журнал - я не в курсе.
2.В журнале есть номер процесса и состояние транзакции, при неожиданном падении процесса (например, его закрыла операционная система) через короткое время каше детектирует ситуацию, проверяет журнал и при необходимости отменяет результат операций.
3.Запись строки таблицы - это один атом операции, т.е. обновить половину полей даже при сбое у вас не получится. Удаление/установка индекса это другая операция, отдельно установка и отдельно удаление.

При падении всей системы проводится проверка операционного журнала, при необходимости транзакция откатывается или наоборот, дописывается в базу.
Операция инкремента счетчиков не журналируется, поэтому при падении базы строки данных запишутся в базу в любом случае, а счетчик может и не записаться. Эту ситуацию получить сложно, а исправить легко. Искусственно я ронял тестовую каше ресетом несколько раз для проверки надежности, в итоге повторения ошибки не добился, а операционную систему и железо стало жалко.

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

Низкоуровневую логику базы данных нарушить тоже можно, но для этого нужно либо особое везение + либо какие-то нечеловеческие издевательства (вариант - неисправная дисковая система). Исправить нарушение внутренней структуры можно.

Для примера По области начались ураганы... Но это не останавливает нашу клиентуру. Свет рубили и не раз! Но они снова и снова запускали Каше - упал сам сервер, целостность баз данных не нарушена.

Также, в каше есть горячие бэкапы и shadow/mirror.
Т.е. надежность не является проблемой каше.

-------
Приведенный пример с 80000 операций/с это, если не ошибаюсь, пилотный проект электронной биржи, либо чего связанного с биржей. Насколько я понял, транзакции конкретно в этом месте не использовались. Ну если у биржи кто-то выдернет UPS-ник, то я даже не знаю :-)

DPH3Ну и зачем тогда сравнивать скорость bulk insert c скоростью атомарной записи в SQL-базах?
Вы опять не поняли. Это совсем не скорость записей в базу. Это скорость записи данных из внешнего приложения. И я узнал об этом примере именно как о демонстрации тесноты интеграции каше и java, а не как о примере скорости каше.

Проект реальный, и замена другой реально работающей системе, которая "не шмагла". На чем уж она там была написана, а не в курсе.

DPH3Ну и нагрузки смешные, 250 000 операций в день - и зачем там нужно масштабирование?
А уж то, что необходима поддержка специалистов вендора для импорта данных по какому-то миллиону новых абонентов - звучит крайне странно. А теперь я не понял, вы о чем?
250000 в день это не то чтобы смешные нагрузки - запросы бывают разные, но как демонстрация скорости не канает, согласен. Я правда не понял, откуда эта цифра.

По поводу специалистов вендора я опять же не понял, о чем вы? Мне известно только о поддержке специалистов вендора при разработке новой системы и миграции старой системы в новую.
Но при чем тут количество абонентов?

Вообще меня в этой дискуссии раздражает роль суррогата маркетинговой службы ИС.
Несколько лет назад на нас косились "хаха-смотрите, придурки без SQL работают, ну и дикари" (хотя SQL в каше есть).
Так и сейчас приходится доказывать, что не верблюд.
Говоришь, что каше есть и у нее есть какие-то возможности и какие-то преимущества - смотрят, как будто прибыл с марса и рассказываю про марсианские яблони. Ну честное слово :-)
Все, что маркентинговая служба несет в массы воспринимается на уровне рекламы виагры.
Но мы есть, мы настоящие. И мы не виагра :-)