metaclass | Перепост, про Firebird

Перепост, про Firebird

ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной Firebird, и надо переходить на "промышленные" СУБД.
...
Правильно затюнигованный Firebird держит 1500 активных клиентских подключений, обслуживает 400Гб базу, и экономит предприятию как минимум от $6000 за каждый процессор.

У меня на почве Firebird когнитивный диссонанс в крайней стадии.
Во-первых, он у меня работает в количестве нескольких сотен штук у разных клиентов. Во-вторых, я на его использовании съел собаку. В третьих, у меня кодогенератор пока заточен строго под Firebird и свои модели хранит тоже в Firebird. То бишь мне по долгу службы положено всюду Firebird пропагандировать и пиарить.

Но периодически возникают срачи с разного рода админами, коллегами-программистами и прочими причастными к теме, и все они крайне не любят оный Firebird. Типа истории про неуловимый баг "если в процессе работы почитать(скопировать) базу извне сервера, то база сдохнет. Оригинал сдохнет, не копия". Ну и прочие urban legends. У людей без мозгов вообще первая реакция примерно такая: "Firebird? А, ну идите в топку, пионеры из НИИГиТ.".

Ребе

theiced вообще убеждает меня, что базы Firebird регулярно отправляются на марс, со всеми данными :) И таки да, надо признать, такое бывало, меньше 1% случаев, но бывало. Я не знаю, как обстоят с таким дела у всяких Ораклов или PostgreSQL, но меньше 1% излечимых отказов, при жестоко удолбищных условиях эксплуатации - это имхо, вполне хорошо. Возможно, я чего-то не понимаю, и отказов вообще быть не должно.

Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.

И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.

Flat | Top-Level Comments Only

Вот тута подробненько вся эта ситуация Pg + 1с описана.
http://www.gilev.ru/1c/81/postgresql/

Да, с блокировками одинэс решил у себя ничего не трогать а ковыряться в Pg.

Короче один фиг - работать нормально невозможно.

А про работу 1с с ораклом - откуда такая инфа?

во-первых, Вы можете зайти на официальный сайт 1с. я об этом писал, но Вы ж букварь еле осилили.. http://v8.1c.ru/overview/Term_000000135.htm
во-вторых, если это действительно так интересно - пройти официальный курс администрирования oracle для 1с. кстати, г-на Гилева я там видел среди слушателей.

по поводу блокировок - перечитайте гилевский текст пару раз. может быть, что в голове появится. но я в этом очень не уверен.

Оракл идет нафиг. Если я правильно понял то ограничения XE нам не подходят. А покупать оракла для 1с нет никакого смысла. Проще купить MS SQL на который оно и заточено.

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

В принципе, сквозное решение на том же 1с было бы нормальным вариантом. Но поскольку на железо и админа денег нет, то остается 1с для бухгалтерии и самописка непонятно кем без разницы на чем - для остальных.

SAP не нужен, даже даром.

Сквозное решение на 1с нормальным вариантом у нас не считается ибо имеет совершенно неправильные требования к железу и софту. И возню с лицензиями - и на TSE и на 1с и на MS SQL. Тем более что одно и то же самописное решение у нас применяется и в филиалах. В случае одинэса пришлось бы покупать все это и туда.

Это вопрос не отсутствия денег а в отсутствии смысла использовать решения которые еще потом требуют платы за лицензии. Ибо и в случае с 1с все равно получается самописка.

все стоит денег. даже 1с.
винда и офис стоят денег.
серверы стоят денег.
- какая новость..

Понятно что все стоит денег.
Самописка тоже стоит денег, и не малых.
Просто если вложился в самописку на безлицензионных инструментах - потом без проблем тиражируешь решение где угодно и дополнительных расходов на лицензии кроме как на средства разработки (да и то если взять тот же питон - могло быть и бесплатно) уже не требуется. В случае с одинэсом для каждое клиентское место надо потратиться на лицензии
- 1с
- TSE
- MS SQL.

Даже если разработка на одинэсе стоит дешевле чем разработка на D+FB (что не факт) - то каждое рабочее место в дальнейшем эту разницу съедает + еботня с собственно лицензиями и с ключами защиты которые тоже поглючить любят. Т.е. за свои же деньги осложняем себе же жизнь.

перевод софта с одного сервера на другой - тоже стоит денег, оченно не малых. И времени.
Поэтому вполне возможный вариант - вместо того что бы тратить N времени и денег - спонсируем FF на внеочередное выполнение задачи, скажем - tablespase мне вот понадобится. Оно в планах там конечно стоит, но не в первоочередных наверное. За бабки можно форсировать. Т.е. вместо того что бы тратить эти бабки на переход с одного сервера на другой - можно потратить те же бабки (условно) и получить нужное решение в своем сервере, и ничего переделывать не надо.

> перевод софта с одного сервера на другой - тоже стоит денег, оченно не малых. И времени.
- это Вы о чем? установить ОС, серверы БД и приложений? что тут немалого по деньгам и времени?

> спонсируем FF на внеочередное выполнение задачи, скажем - tablespase мне вот понадобится.
- все. я выхожу из игры. спонсировать какое-то говно, где нет вакуума, тейблспейсов..
я не вижу ни малейшего повода дальше это говно с чем-то сравнивать. говорить не о чем.

А расскажите какой-нибудь use case для tablespace.

Я представляю как-то в общих чертах, типа "разложить таблицы по разным физическим дискам, в зависимости от интенсивности и профиля использования", а как они реально используются?

Там даже таблицу можно разделить в разные спейсы. Но, как всегда дъявол в деталях. На такие таблицы и на их индексы есть масса ограничений.
Можно наверное еще таблицу в одно место а индекс от нее - в другое.

Кстати то что объекты в PG лежат в отдельных файлах облегчило создание TS.
Типа как в FB - external file.

- реально так и используются.
у того же оракла -
*

Separate user data from data dictionary data to reduce I/O contention.
*

Separate data of one application from the data of another to prevent multiple applications from being affected if a tablespace must be taken offline.
*

Store different the datafiles of different tablespaces on different disk drives to reduce I/O contention. - это часто.
*

Take individual tablespaces offline while others remain online, providing better overall availability.
*

Optimizing tablespace use by reserving a tablespace for a particular type of database use, such as high update activity, read-only activity, or temporary segment storage.
*

Back up individual tablespaces.

Это я о том что вам похоже недоступно, поскольку вы не разработчик.

Нельзя безболезненно перейти с одного сервера на другой если база чуть сложнее телефонного справочника.
Случай с одинэсом - характерный пример, причем у них в БД вообще никакой логики и процедур не зашито. А если в базе кучка процедур и триггеров то все это переписать с учетом другого сервера, его языка и архитектуры, и все это отладить и протестировать... И естественно все это затрагивает и клиентскую часть.В некоторых случаях проще переписать с нуля. Но и ценник соответственный.

- формулируйте по-человечески. или не скачите с темы на тему. - то о железе разговор, то о софте..
впрочем, разговор окончен. не о чем.

Я отвечаю на ваш вопрос - откуда берется стоимость перехода с одного сервера на другой. Железо тут ни при чем и про него я и не заикался в этом ответе. Вы за мыслями следите да?

Объясняю еще раз, в одном месте. Перенести базу с одного сервера на другой (например с FB на PG) - это то же самое что переписать программу с Delphi на Pyton. Куча ебли при нулевом смысле.

pytHon, конечно, если вас это задевает.

вот это

- сервер.

а есть еще почтовые серверы, веб серверы, серверы БД, серверы приложений и так далее.

но человек, который с "унутре" разбирается, но ни черта не слышал про блокировки, ни вообще о том, что бывает на свете, - ему ж пофигу.

> Перенести базу с одного сервера на другой (например с FB на PG) - это то же самое что переписать программу с Delphi на Pyton.
- смысл есть, только Вы его не видите. и с Delphi на python - тоже есть. Но Вы его опять-таки не видите и не понимаете.

Если для вас до сих пор не дошло - речь про перенести с сервера [БД] Firebird на сервер [БД] Postgres о чем вы мне тут талдычите уже который день.

(no subject)

sgalitsky.livejournal.com - 2011-04-14 11:25 (UTC) - Expand

Ну-ка объясните в чем смысл мне переписываться
- с Firebird на PostgreSQL
- c Delphi на Python
?
Хотя бы пару реальных аргументов - что станет лучше.

Вакуума нет потому что он в FB не нужен.
Я с таким же успехом могу обвинять Postgre что в нем есть такой костыль как вакуум и с ним надо периодически ебстись.

> Вакуума нет потому что он в FB не нужен.
- почему он не нужен в fb?

Потому что сборка мусора осуществляется кооперативно.

Передвижение OAT/OIT и попутно сборка мусора осуществляется SWEEP - автоматом по указанному разрыву между OAT/OIT или принудительным запуском.
Поэтому вакуум не нужен.

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

Почитал про этот ваш VACUUM и что он делает.

В FB нет журнала/лога транзакций в понимании Pg.
Все версии записей хранятся в самой базе.
Индексы неверсионные, они видят все версии сразу.
При чтении/обновлении/удалении записей сначала определяется что же мы должны видеть а что нет, в соответствии с уровнем изоляции текущей транзакции. Ищутся все версии нужной нам записи, по ним определяется что мы должны видеть а так же есть ли транзакции которые интересуются этими версиями. Если найдены версии в которых никто не заинтересован - они удаляются, место освобождается и будет использовано впоследствии. Для того что бы при изменении записей было куда сложить версии и их не раскидывало по всей базе - обычно на каждой странице оставляется порядка 20% свободного места. Но если оно кончится - не страшно - будет любое другое свободное в базе или если его нет - добавлена новая страница. Если база только для чтения - ее можно отресторить с ключиком "не оставлять пустого места" - база будет несколько меньше.
Таким образом удаление ненужных версий происходят при каждом обращении к данным, но удаляются версии созданные не в этой транзакции. Для того что бы принудительно убрать мусор созданный в транзакции N надо в следующей транзакции прочитать данные которые были изменены в предыдущей. Например
delete from table1
а что бы все действительно удалилось надо сделать например
select count(*) from table1

Соответственно при изменении/удалении больших объемов следующие за текущей транзакции могут подтормаживать занимаясь сборкой мусора от предыдущей. Обращаю внимание что анализируются версии только тех записей к которым мы обращаемся, т.е. если после

delete from table1
из миллионной таблицы делается
select field from table1 where id = 1
то мусор собирается только для версии записи с ID=1 а не для всех записей таблицы и никакого заметного торможения не возникает.

Можно при коннекте к базе указать что этот коннект не хочет заниматься сборкой мусора - и он соответственно не будет это делать. С одной стороны это может ускорить его работу. С другой стороны если мусор никто не собирает - то это увеличивает размер базы и в итоге замедляет всех т.к. приходится просматривать много версий записей, в том числе уже никому не нужных.

Чтение всех записей бывает например при бэкапе базы. Но если бэкап надо сделать быстро и есть подозрение что в базе много мусора - можно отказаться от сбора мусора при бэкапе ключиком -G.

Версии записей могут порождаться не только изменениями но и операциями чтения, к примеру транзакциям REPEATABLE READ.

Все это я описал очень упрощенно.

Многие административные в Pg вещи в FB определяются еще на стадии написания приложения.

>> спонсировать какое-то говно.

Вы исходите из того что FB гавно и никаких аргументов не приемлете.
Я исхожу из того что даже если у меня возникнет потребность в таблеспейсах а их к тому времени еще не сделают - вместо того что бы заморачиваться переводом своего софта на иной сервер со своими глюками, тратить кучу времени и нервов могу просто проспонсировать появление этих таблеспейсов.

Чисто прагматично - заплатить денег или заплатить денег и поебстись.
Ибаццо без смысла мне как-то не интересно.

Flat | Top-Level Comments Only