Pull to refresh
138
0
Алексей Ковязин @AlexeyKovyazin

FirebirdSQL

Send message
К сожалению, пример «носитель гена умный > грамотный > применяет вакцины > выжил и дал потомство» неверный на уровне статистики: у семей с высоким уровнем образования число детей существенно меньше, чем у малообразованных, в тоже время, малообразованные пользуются достижениями медицины, не углубляясь в особенности (ну и ставят потом свечку).
А мы сами про rkeeper много чего знаем — нам довольно постоянно присылают БД на починку с «серверов» из ресторанов и кафе, причем часто это такие сервера, которые с 2003 не пылесосились, и «вдруг» сломались. Сложно представить себе любую другую СУБД, которая выжила бы 10-15 лет в подсобке на IDE диске, между посудомойкой и духовкой, без УПСов и ECC RAM. Но почему разработчики rkeeper не могут сделать бат файл из одной строки, который бы бэкапил их БДшки хоть куда нибудь, я понять не могу, но СУБД то тут точно не причем, верно? :)
Запрошенные комментарии тянут на пару глав в книге :) Статья и так довольно объемная получилась — и, как Вы сами правильно заметили, мы вопрос тюнинга на семинарах и конференциях Firebird постоянно освещаем. Коротко — VMA надо увеличить из фрагментации памяти, число потребляемых VMA легко мониторится, до 2000 юзеров 250К достаточно (не надо рассказывать как VMA мониторить? :) Ограничить дефолтный DefaultDBCachePages — это полезная соломка из нашей практики. Файловый кэш всякой линуксовой СУБД нужен — если это не MSSQL, конечно :) TempCacheLimit — определить очень легко, используя HQbird с параметром TempSpaceLogThreshold (TempCacheThreshold). По лок таблице теория на отдельную статью тянет, причем довольно бесполезную статью, т.к. рекомендация точно такая же будет.
Да, лучше статью написать, раз есть интерес :)
Ну как сказать, кто — вот Вы, после бессонной ночи отладки Ангуляра, идете во Вкусвилл, а там Firebird внутри POS Frontol-а — отвратительно! Заказчик прислал бабки за вебсайт, идете смотреть курс бакса на Мосбирже, а там тоже Firebird — ужас-ужас! Приставы списали деньги за неоплаченный штраф — и там ведь Firebird, зараза (а до того — и в компьютере у мирового судьи). От таких переживаний плохеет, идете в аптеку купить витаминов — а там тройной удар — производитель витаминов Фармстандрт, аптечные дистрибуторы и сама аптека тоже имеет POS на Firebird! В частные больницы лучше не соваться, это уже понятно из статьи, в государственных да — MSSQL, госуслуги, можно попробовать. В общем, от всего этого Вы расстраиваетесь, решаете покинуть #этустрану, берете билет на Аэроэскпресс — ааа! Опять жар-птица! Добравшись до аэропорта, садитесь в лайнер Аэрофлота, но и там работает эта клятая СУБД… И наконец, взлетев на Боинге — осознаете, что Боинг то тоже использует Firebird.
Почему не сделали — потому что задача репликации и шардирования реляционной СУБД с поддержкой полноценных транзакций раз в несколько посложнее всей реализации Кубиков, а как сделать ее красиво и дешево с разбросом по N нодам, пока никто не придумал. Да, есть мультимастер репликация, но до желаемой легкости и производительности там еще очень далеко, оттого RAC все еще на коне.
Привет. Спасибо за статью. Очень хотелось бы небольшую статью-спинофф с более подробным обоснованием «Если мы умные люди и не держим базу в кубере». Сейчас все больше людей, которые хотят держать БД в контейнере… как им объяснить, почему это плохо?
Про РедБазу не стоит ли сделать подобный рассказ? Про внедрение на 10 тыс коннектов рассказать, и другие успехи?
Хорошая статья, спасибо! Скажите, а не разбирались ли вы с вопросом о шифровании данных — в каких случаях оно нужно, в каких настоятельно рекомендуется?
Статья начинающего холивращика :)
Вот тут ключевая ошибка
>Нужно использовать данные из другой СУБД — просто делаете запрос в другую БД и спокойно
>работаете с этими данными.

Единая БД — чертовски удобное место для манипуляции данными, и практически единственное, если нужно работать с большими объемами согласованнымх, транзакционных данных.
Представьте, что данные по продажам какого нибудь Дикси лежат в одном экземпляре БД, а данные по скидочным акциям контрагентов — в другом. И как тут спокойно создать, скажем, отчет по ребэйтам — тащить все миллиарды записей в миддлваре и там компоновать?
Стоимость межпроцессных взаимодействий никто не отменял, и если можно затолкать все данные в одну БД — надо заталкивать.
Все инвестиции характеризуются временным горизонтом и возвратом. Потенциально у инвестиций в продление жизни очень большой возврат, но их горизонт сильно превышает способность обычного человека к планированию. Ну и обычная суета жизни мешает выглянуть за пределы обыденности. Так и мрут все, включая миллиардеров.
Хорошая статья — но не хватает второй части, посвященной отладке. Теперь, когда появились CRISPR и прочие механизмы редактирования генома, возможно проводить «отладку» — т.е. менять гены, смотреть на результат. Т.к. цикл такой отладки зависит от жизни организма, и обычно очень длинный, надо проводить ее в параллельных потоках — одновременно запускать сотни или даже тысячи изменений.
>1. Недуракоустойчивая. Можно сделать невосстановимый бэкап gbak, например (я даже >сначала не поверил такому нонсенсу).

Только для тех, кто сидит на версиях до 2004 года. Начиная с 1.5 появился переключатель -no_validity, который восстанавливает в любом случае.

>2. MVCC без лога приводит к тому, что при транзакциях нужно делать много изменений >по всему файлу данных.
>Соответственно, при сбое питания или внезапном ресете шанс похерить базу возрастает >многократно.

В Firebird используется механизм Careful Writes, внедренный в в 80-х годах в InterBase. Именно благодаря этому механизму InterBase работал на системах залпового огня MLPRS для хранения, в которых вся система перегружалась из-за магнитного удара.

Да неужели :) Как раз наоборот, перевести деньги из/в ЮАР или Бразилию, как и в РФ — замучаешься оформлять и объяснять. И налоговая нагрузка под 100%, если говорить о продаже лицензий.
Если есть вопросы у правоохранительных органов — так у них есть полномочия прийти и все проверить — но спрашивается, при чем тут банки. Я не вижу никакого другого объяснения, что где то в недрах ЦБ или Минфина сидит старый чинуша из Госплана СССР, лет под 80, который натягивает советское отношение к валюте на нынешнюю реальность. Причем — все это строго для обычных людей, системообразующие предприятия зареганы на оффшоры и возвращаться не торопяться, для них ВК идет по зеленому трубопроводу. Я не в претензии к Модулю, люди в ВК там хорошие, помогают и оформляют, но общий идиотизм ситуации напрягает.
Интересно, какие там риски, не поделитесь? Без проблем можно платить в Европу, США, Австралию, но как только доходит до стран 3-го мира, типа Бразилии, Южной Африки, России — появляются невменяемые правила. У правоохранительных органов есть все данные о переводах, и все полномочия проверять любые сделки, зачем сплошной контроль? Как выше верно заметили — зачем ограничивать приток валюты? Это при том, что с оттоком никто похоже не борется: полстраны по прежнему оформлено в оффшорах, на закон о КИК все плевали с высокой колокольни, а утечка средств достигает каких-то фантастических размеров. Последние измененения в валютном контроле слегка облегчают получение валюты до 1000 долларов, но надо вообще отменять контроль до 50 тыс входящих.
Нравятся мне абстрактные рассуждатели… Позвоните своему отцу и спросите, когда он собирается умереть, и что предпринимает, чтобы не зажиться ненароком и принести убыток обществу (Пенсионному Фонду, в основном). А потом поднапрягите абстрактную рассуждалку, и на себя это спроецируйте — и если сейчас Вам 20 лет и жизнь кажется бесконечной, то в 30 это будет по другому. И, конечно, напишите сюда — что собираетесь сделать для предотвращения своего излишне долго существования.

Даже Firebird 2.5 на правильном железе держит 1500 и выше коннектов, во вполне себе нагруженных проектах, когда есть грамотные ДБА или профессиональное сопровождение. И кстати, на Firebird действительно много такси-сервисов написано и работает, обычно на дефолтных конфигурациях, т.е. вообще без оптимизации и без ДБА.
Господа, спор о третьих лицах (обманывают или не обманывают, пропитывают/подменяют ли и прочее) бесперспективен. Практически надо подходить к вопросу — почему огонь сходит в день православной пасхи? Их в мире около 250млн, в то же католиков миллиард, полтора млрд мусльман, сотни миллионов индуистов, и другие религии… Как гарантированно попасть в рай в таких условиях — почему нужно верить в религию с благодатным огнем, а не в религию с пророком?
Ответа на вопрос не требуется :)
У молодежи всегда складывается впечатление, что технологии, которые запустились раньше их трудовой карьеры — дикое устаревшее старье :) Про то, что цикл жизни ERP и прочего энтерпрайза составляет лет 20, мало кто знает.
Баланс вряд ли поможет в решении основной проблемы, обозначенной в статье.
Надо хакать программу старения.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity