Исправление byko3y, (текущая версия) :
Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика
Нужно хранить связанные сущности связанными, а между независимыми сущностями целостность не важна. Конечно, есть задачи, которые требуют обязательной глобальной целостности, вроде финансовых отчетов. Но такие запросы, как правило, не выполняются по сотне раз на дню и в любом случае сильно нагружают систему — хотя бы необходимостью держать этот снимок в кэше.
Я даже больше скажу: уровень целостности данных «снимок» тоже не гарантирует, что потребитель получит корректную информацию. Потому что товар уже продан, а в снимке он еще на складе. А при акценте на причинную целостность, то есть, на целостность тесно связанных сущностей, клиент получает возможность получить актуальные сведения по интересующим товарам вместо бесполезного снимка всей БД в прошлом.
А я вот, например, до сих пор не знаю, как в РСУБД решить проблему проверки инвариантов без применения максимального уровня целостности (блокировки таблиц целиком), если эта проверка не встроенна в эту СУБД, вроде проверок уникальности индекса или внешних ключей. Например, у меня есть нечеткое сравнение наименований и мне нужно убедиться, что похожего товара нет в базе. Индексы здесь бесполезны, потому что ни в одну СУБД не встроена нечеткая проверка уникальности. Иерархичная же организация подобного индекса позволяет производить блокировку отдельных ветвей.
В такой связанно-иерархической организации получается, что даже на распределенной системе невозможно овербукнуть полет, потому что существует координатор, который, грубо говоря, обслуживает запросы по всем самолетам вылетающим из одного аэропорта — и не нужно никакой глобальной целостности и снимков. Я подозреваю, что NYSE примерно так и работает. Эта мания хранить всё в центральном хранилище, подогреваемая SAP и Oracle, лишь приводит к неоправданно завышенным требованиям к системе, и по итогу к vendor-lock-у на те немногие программные и аппаратные решения, которые способны этим требования удовлетворить. Вроде SAP HANA на машине с 8 Тб (терабайт) оперативы — это вполне реально существующие современные сервера для крупного бизнеса.
Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных
Мне кажется, что ты описываешь здесь какую-то очень конкретную систему, подразумевая именно ее одну под целым набором методов разработки БД. Так-то причинная целостность может быть реализована и синхронно, и асинхронно, и без мастера вообще (то есть, систему нельзя ужать до одного узла, работоспособность ее обеспечивается только комбинацией этих узлов) — и тогда ни у кого нет полной копии данных. А зачем она нужна?
Исправление byko3y, :
Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика
Нужно хранить связанные сущности связанными, а между независимыми сущностями целостность не важна. Конечно, есть задачи, которые требуют обязательной глобальной целостности, вроде финансовых отчетов. Но такие запросы, как правило, не выполняются по сотне раз на дню и в любом случае сильно нагружают систему — хотя бы необходимостью держать этот снимок в кэше.
Я даже больше скажу: уровень целостности данных «снимок» тоже не гарантирует, что потребитель получит корректную информацию. Потому что товар уже продан, а в снимке он еще на складе. А при акценте на причинную целостность, то есть, на целостность тесно связанных сущностей, клиент получает возможность получить актуальные сведения по интересующим товарам вместо бесполезного снимка всей БД в прошлом.
А я вот, например, до сих пор не знаю, как в РСУБД решить проблему проверки инвариантов без применения максимального уровня целостности (блокировки таблиц целиком), если эта проверка не встроенна в эту СУБД, вроде проверок уникальности индекса или внешних ключей. Например, у меня есть нечеткое сравнение наименований и мне нужно убедиться, что похожего товара нет в базе. Индексы здесь бесполезны, потому что ни в одну СУБД не встроена нечеткая проверка уникальности. Иерархичная же организация подобного индекса позволяет производить блокировку отдельных ветвей.
В такой связанно-иерархической организации получается, что даже на распределенной системе невозможно овербукнуть полет, потому что существует координатор, который, грубо говоря, обслуживает запросы по всем самолетам вылетающим из одного аэропорта — и не нужно никакой глобальной целостности и снимков. Я подозреваю, что NYSE примерно так и работает. Эта мания хранить всё в центральном хранилище, подогреваемая SPA и Oracle, лишь приводит к неоправданно завышенным требованиям к системе, и по итогу к vendor-lock-у на те немногие программные и аппаратные решения, которые способны этим требования удовлетворить. Вроде SAP HANA на машине с 8 Тб (терабайт) оперативы — это вполне реально существующие современные сервера для крупного бизнеса.
Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных
Мне кажется, что ты описываешь здесь какую-то очень конкретную систему, подразумевая именно ее одну под целым набором методов разработки БД. Так-то причинная целостность может быть реализована и синхронно, и асинхронно, и без мастера вообще (то есть, систему нельзя ужать до одного узла, работоспособность ее обеспечивается только комбинацией этих узлов) — и тогда ни у кого нет полной копии данных. А зачем она нужна?
Исправление byko3y, :
Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика
Нужно хранить связанные сущности связанными, а между независимыми сущностями целостность не важна. Конечно, есть задачи, которые требуют обязательной глобальной целостности, вроде финансовых отчетов. Но такие запросы, как правило, не выполняются по сотне раз на дню и в любом случае сильно нагружают систему — хотя бы необходимостью держать этот снимок в кэше.
Я даже больше скажу: уровень целостности данных «снимок» тоже не гарантирует, что потребитель получит корректную информацию. Потому что товар уже продан, а в снимке он еще на складе. А при акценте на причинную целостность, то есть, на целостность тесно связанных сущностей, клиент получает возможность получить актуальные сведения по интересующим товарам вместо бесполезного снимка всей БД в прошлом.
А я вот, например, до сих пор не знаю, как в РСУБД решить проблему проверки инвариантов без применения максимального уровня целостности (блокировки таблиц целиком), если эта проверка не встроенна в эту СУБД, вроде проверок уникальности индекса или внешних ключей. Например, мне у меня есть нечеткое сравнение наименований и мне нужно убедиться, что похожего товара нет в базе. Индексы здесь бесполезны, потому что ни в одну СУБД не встроена нечеткая проверка уникальности. Иерархичная же организация подобного индекса позволяет производить блокировку отдельных ветвей.
В такой связанно-иерархической организации получается, что даже на распределенной системе невозможно овербукнуть полет, потому что существует координатор, который, грубо говоря, обслуживает запросы по всем самолетам вылетающим из одного аэропорта — и не нужно никакой глобальной целостности и снимков. Я подозреваю, что NYSE примерно так и работает. Эта мания хранить всё в центральном хранилище, подогреваемая SPA и Oracle, лишь приводит к неоправданно завышенным требованиям к системе, и по итогу к vendor-lock-у на те немногие программные и аппаратные решения, которые способны этим требования удовлетворить. Вроде SAP HANA на машине с 8 Тб (терабайт) оперативы — это вполне реально существующие современные сервера для крупного бизнеса.
Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных
Мне кажется, что ты описываешь здесь какую-то очень конкретную систему, подразумевая именно ее одну под целым набором методов разработки БД. Так-то причинная целостность может быть реализована и синхронно, и асинхронно, и без мастера вообще (то есть, систему нельзя ужать до одного узла, работоспособность ее обеспечивается только комбинацией этих узлов) — и тогда ни у кого нет полной копии данных. А зачем она нужна?
Исходная версия byko3y, :
Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика
Нужно хранить связанные сущности связанными, а между независимыми сущностями целостность не важна. Конечно, есть задачи, которые требуют обязательной глобальной целостности, вроде финансовых отчетов. Но такие запросы, как правило, не выполняются по сотне раз на дню и в любом случае сильно нагружают систему — хотя бы необходимостью держать этот снимок в кэше.
Я даже больше скажу: при уровень целостности данных «снимок» тоже не гарантирует, что потребитель получит корректную информацию. Потому что товар уже продан, а в снимке он еще на складе. А при акценте на причинную целостность, то есть, на целостность тесно связанных сущностей, клиент получает возможность получить актуальные сведения по интересующим товарам вместо бесполезного снимка всей БД в прошлом.
А я вот, например, до сих пор не знаю, как в РСУБД решить проблему проверки инвариантов без применения максимального уровня целостности (блокировки таблиц целиком), если эта проверка не встроенна в эту СУБД, вроде проверок уникальности индекса или внешних ключей. Например, мне у меня есть нечеткое сравнение наименований и мне нужно убедиться, что похожего товара нет в базе. Индексы здесь бесполезны, потому что ни в одну СУБД не встроена нечеткая проверка уникальности. Иерархичная же организация подобного индекса позволяет производить блокировку отдельных ветвей.
В такой связанно-иерархической организации получается, что даже на распределенной системе невозможно овербукнуть полет, потому что существует координатор, который, грубо говоря, обслуживает запросы по всем самолетам вылетающим из одного аэропорта — и не нужно никакой глобальной целостности и снимков. Я подозреваю, что NYSE примерно так и работает. Эта мания хранить всё в центральном хранилище, подогреваемая SPA и Oracle, лишь приводит к неоправданно завышенным требованиям к системе, и по итогу к vendor-lock-у на те немногие программные и аппаратные решения, которые способны этим требования удовлетворить. Вроде SAP HANA на машине с 8 Тб (терабайт) оперативы — это вполне реально существующие современные сервера для крупного бизнеса.
Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных
Мне кажется, что ты описываешь здесь какую-то очень конкретную систему, подразумевая именно ее одну под целым набором методов разработки БД. Так-то причинная целостность может быть реализована и синхронно, и асинхронно, и без мастера вообще (то есть, систему нельзя ужать до одного узла, работоспособность ее обеспечивается только комбинацией этих узлов) — и тогда ни у кого нет полной копии данных. А зачем она нужна?