Исходное сообщение
"Компания Bloomberg открыла код распределённой СУБД Comdb2" Отправлено Аноним, 14-Июн-17 16:38
>Расскажи, каким образом ACID накладывает ограничение в 2к записей в секунду? 1. Читаем определение: https://ru.wikipedia.org/wiki/ACID 2. Читаем pdf-файл, что я дал выше. 3. Делаем выводы, что чтобы обеспечить ACID в кластере, при полной синхронизации транзакций нужно делать логику, которая способна разруливать простейшие вещи. Такие как, вставка на одной ноде, и следом за ним удаление этой новой записи на другой ноде. Технические детали, как это выполнено в comdb2 описаны в документе выше. Также, в этом же документе описывается почему низкая скорость записи: Параграф 7. Current Work >Comdb2 is also limited today in its ability to scale writes. >While reads scale in a nearly linear manner as cluster size in- >creases, writes have a more conservative level of scaling with >an absolute limit. Ключевое слово "an absolute limit". И далее прописывается ряд деталей о подводных камнях. А точнее цена расплаты за все "удовольствия". >А чья забота? Страховой? Потеря последних записей при отключении питания - это не теоретическая проблема с околонулевой вероятностью, а обыденная реальность. 1. Человека. Человек может поставить UPS. Купить рейд с батарейками и даже выделить резервный источник питания от ДРУГОЙ электростанции. 2. Как я говорил, забота ложится на железку, драйвер и ФС. Последняя кстати, может предотвратить искажение последней записи, сделав откат или накат из журнала. Еще вопросы?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>Расскажи, каким образом ACID накладывает ограничение в 2к записей в секунду? > 1. Читаем определение: https://ru.wikipedia.org/wiki/ACID > 2. Читаем pdf-файл, что я дал выше. > 3. Делаем выводы, что чтобы обеспечить ACID в кластере, при полной синхронизации > транзакций нужно делать логику, которая способна разруливать простейшие вещи. Такие как, > вставка на одной ноде, и следом за ним удаление этой новой > записи на другой ноде. Технические детали, как это выполнено в comdb2 > описаны в документе выше. Также, в этом же документе описывается почему > низкая скорость записи: > Параграф 7. Current Work >>Comdb2 is also limited today in its ability to scale writes. >>While reads scale in a nearly linear manner as cluster size in- >>creases, writes have a more conservative level of scaling with >>an absolute limit. > Ключевое слово "an absolute limit". И далее прописывается ряд деталей о подводных > камнях. А точнее цена расплаты за все "удовольствия". >>А чья забота? Страховой? Потеря последних записей при отключении питания - это не теоретическая проблема с околонулевой вероятностью, а обыденная реальность. > 1. Человека. Человек может поставить UPS. Купить рейд с батарейками и даже > выделить резервный источник питания от ДРУГОЙ электростанции. > 2. Как я говорил, забота ложится на железку, драйвер и ФС. Последняя > кстати, может предотвратить искажение последней записи, сделав откат или накат из > журнала. > Еще вопросы?
	Введите код, изображенный на картинке: