Так автор и говорит, что в 2003 проект начинался и до сих пор живет и здравствует. Некоторыми фичами некоторые "современные альтернативы" до сих пор не могут похвастаться (блочные бэкапы, автономные транзакции, MERGE то некоторые только недавно сумели доделать). Если все прекрасно работает, зачем какой-то выбор альтернатив и прочее?
Про нормальный фреймворк на Го ждите статью в новом году.
И про продукту Ред) я, извините, все равно напишу. РБД Эксперт надо посмотреть, если возникает вопрос альтернатив под Линукс, особенно если Вы его последний раз видели до обновления дизайна.
Спасибо за статьи! Очень интересный опыт и методика погружения. Думаю очень полезно будет тем, кто хочет научится читать чужой код. Это может быть не обязательно Firebird.
Верно, работа nbackup реализована через дельта файл. К WAL это отношения не имеет и свою задачу решает четко и имеет полезные эффекты. WAL это не фича. WAL это способ реализации. Не единственный. Кроме того, инкрементальный бэкап истинно инкрементальный только для изменившихся страниц. Да еще и инкременты можно отсчитывать от разных событий одновременно.
Логический дамп тоже online.
Для PITR есть варианты через журналы асинхронной репликации и инкременты. Встроенная реализация в бэклоге.
У нас jvm тоже запущена из ядра и тоже работает с базой напрямую из ядра. JDBC только интерфейс. А драйвер мы тоже контрибьютим и развиваем.
Про лог транзакции. То вы утверждали что все сбоит. Теперь понятно что нет, но оказывается медленно. Практика показывает что все хорошо при правильном подходе.
Был бы очень благодарен за тьму сценариев повреждения файлов. А в случае сбоя ничего не надо накатывать. Все целостно и так. Нулевое время восстановления. Ни одна СУБД так не умеет.
На той, чтобы предоставить обычный доступ к интерфейсу JDBC внутри той-же или новой транзакции и позволить внешней подпрограмме получить доступ к содержимому БД с целью обработки данных.
По надежности вы понимаете неверно. СУБД Ред База Данных поддерживает все свойства ACID и всегда поддерживала. Лог транзакций не единственный способ обеспечения этих свойств. Применяется так называемый Careful Write, поддерживающий консистентное состояние БД на диске в любой момент времени. Посмотрите на канале Ютуб курс "Администрирование". Там об этом было. Или следите за каналом. Мы планируем подробнее об этом рассказать.
А вот именно это я тоже не могу понять. Ссылок нет, кто автор не понятно и что имел в виду тоже. Потерь данных не зафиксировано. Более того есть инструмент чтобы пользователи могли следить за делопроизводством.
В статье википедии эти правки внесены анонимом без указания источников. Именно это комментировать не корректно. Но постараюсь ответить на Ваш вопрос.
На сегодняшний день суммарный объем ЦБД достигает 240ТБ. А отдельно взятой 15ТБ. Предел для СУБД Ред База Данных 3.0 составляет 64ТБ. В версии СУБД Ред База Данных 5.0 этот предел значительно увеличен за счет табличных пространств. Об этом можно послушать тут.
Решение не использовать единую БД обуславливается не максимально допустимым пределом, а рядом других факторов: доступные носители (диски), архитектура системы, удобство администрирования, масштабируемость и кластеризация на уровне сервера приложений. Детали разглашать не буду. Извините.
Касательно показателей нагрузки, это наблюдается в подсистеме межведомственного взаимодействия, где нагрузка на службу одна из крупнейших в стране.
Бэкап/рестор можно запустить в пайпе. Для конвертации это очень хорошо. Позволяет ограничить время временем бОльшей операции. Начиная с 3.0.8 появилась возможность использования множества ядер для выполнения бэкапа и рестора, что кратно должно сократить время.
Так автор и говорит, что в 2003 проект начинался и до сих пор живет и здравствует. Некоторыми фичами некоторые "современные альтернативы" до сих пор не могут похвастаться (блочные бэкапы, автономные транзакции, MERGE то некоторые только недавно сумели доделать). Если все прекрасно работает, зачем какой-то выбор альтернатив и прочее?
Про нормальный фреймворк на Го ждите статью в новом году.
И про продукту Ред) я, извините, все равно напишу. РБД Эксперт надо посмотреть, если возникает вопрос альтернатив под Линукс, особенно если Вы его последний раз видели до обновления дизайна.
SuperServer уже давно имеет общий кеш. И не 1-2 человека. И не по выходным. Приходите на fbconf.ru и освежите представление.
В гите вроде можно увидеть в истории как это было
Спасибо за статьи! Очень интересный опыт и методика погружения. Думаю очень полезно будет тем, кто хочет научится читать чужой код. Это может быть не обязательно Firebird.
Обязательно приходите на fbconf.ru.
Поддерживается Firebird и Ред База Данных. РЕД Эксперт сфокусирован на этих продуктах, но поддерживает их хорошо!
Буду ждать)
Верно, работа nbackup реализована через дельта файл. К WAL это отношения не имеет и свою задачу решает четко и имеет полезные эффекты. WAL это не фича. WAL это способ реализации. Не единственный. Кроме того, инкрементальный бэкап истинно инкрементальный только для изменившихся страниц. Да еще и инкременты можно отсчитывать от разных событий одновременно.
Логический дамп тоже online.
Для PITR есть варианты через журналы асинхронной репликации и инкременты. Встроенная реализация в бэклоге.
А что не так с online-бэкапом например? Бэкапы всегда были вполне себе online всегда в Firebird.
Приходите, все расскажем)
У нас jvm тоже запущена из ядра и тоже работает с базой напрямую из ядра. JDBC только интерфейс. А драйвер мы тоже контрибьютим и развиваем.
Про лог транзакции. То вы утверждали что все сбоит. Теперь понятно что нет, но оказывается медленно. Практика показывает что все хорошо при правильном подходе.
Был бы очень благодарен за тьму сценариев повреждения файлов. А в случае сбоя ничего не надо накатывать. Все целостно и так. Нулевое время восстановления. Ни одна СУБД так не умеет.
На той, чтобы предоставить обычный доступ к интерфейсу JDBC внутри той-же или новой транзакции и позволить внешней подпрограмме получить доступ к содержимому БД с целью обработки данных.
По надежности вы понимаете неверно. СУБД Ред База Данных поддерживает все свойства ACID и всегда поддерживала. Лог транзакций не единственный способ обеспечения этих свойств. Применяется так называемый Careful Write, поддерживающий консистентное состояние БД на диске в любой момент времени. Посмотрите на канале Ютуб курс "Администрирование". Там об этом было. Или следите за каналом. Мы планируем подробнее об этом рассказать.
А вот именно это я тоже не могу понять. Ссылок нет, кто автор не понятно и что имел в виду тоже. Потерь данных не зафиксировано. Более того есть инструмент чтобы пользователи могли следить за делопроизводством.
Здравствуйте!
Спасибо за внимательность и вопрос.
В статье википедии эти правки внесены анонимом без указания источников. Именно это комментировать не корректно. Но постараюсь ответить на Ваш вопрос.
На сегодняшний день суммарный объем ЦБД достигает 240ТБ. А отдельно взятой 15ТБ.
Предел для СУБД Ред База Данных 3.0 составляет 64ТБ. В версии СУБД Ред База Данных 5.0 этот предел значительно увеличен за счет табличных пространств. Об этом можно послушать тут.
Решение не использовать единую БД обуславливается не максимально допустимым пределом, а рядом других факторов: доступные носители (диски), архитектура системы, удобство администрирования, масштабируемость и кластеризация на уровне сервера приложений. Детали разглашать не буду. Извините.
Касательно показателей нагрузки, это наблюдается в подсистеме межведомственного взаимодействия, где нагрузка на службу одна из крупнейших в стране.
Бэкап/рестор можно запустить в пайпе. Для конвертации это очень хорошо. Позволяет ограничить время временем бОльшей операции. Начиная с 3.0.8 появилась возможность использования множества ядер для выполнения бэкапа и рестора, что кратно должно сократить время.
Много полезного есть на канале https://www.youtube.com/c/RedDatabase
Не надо. Уже давно есть IDENTITY COLUMN.
http://www.firebirdsql.org/file/documentation/chunk/en/refdocs/fblangref40/fblangref40-ddl-table.html
тестИровщиков
Наскальная живопись
Что-то не написали они ядро кажется.
Выиграть 5 градусов при таком усложнении вообще штука спорная)
Google Reader-а хватило