BiTel

Использование mysql в качестве БД для биллинга мягко говоря напрягает.
Хотя бы тем, что никто ни за что не отвечает и не гарантирует как эта СУБД будет работать.
Вот например имеем ситуацию, когда при innodb_file_per_table размер файла ibdata1 вырос за 3 месяца до 360Gb и занимает сейчас в 6 раз больше места чем сама база.
Гугление дало что это проблема давно известна http://bugs.mysql.com/bug.php?id=45173, http://bugs.mysql.com/bug.php?id=1341
И всем пофиг. А единственный вариант уменьшить размер файла - задампить БД, все поудалять и восстановить из дампа. Жесть!!!!

Нормальные механизмы бекапа отсутствуют. Варианты с снапшотами и локами БД на время их копирования нормальными назвать сложно.

В самом биллинге очень много кода, заточенного именно под mysql, а не какая-нибудь ORM библиотека. Т.е. безболезненно пересесть на другую БД невозможно.

Товарищи разработчики, как насчет задуматься о выносе БД-специфик кода из ядра и модулей в отдельную библиотеку/прослойку? Тогда ядро и модули будут БД-агностик и переход с одной БД на другую будет решаться в конфиге указанием нужной библиотеки.

Есть огромное желание уйти от mysql на oracle.

овер сикс манс полет нормальный

эээ.....я делаю обычный майэскуэльдамп, и хрен его знает сколько раз восстанавливал уже из него, ниразу проблем небыло, что именно не сохраняется при такой дамповке?
[/quote]

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

это как так? ну… купите платную MySQL, если богаты на оракл. будет вам и поддержка и отвечать будут.

_________________
I'm clever. I've got a computer.

Времени на дамп 60Гб БД и ее восстановление нужно очень много. Абонентам в это время не работать? Или работать но с потерей данных?



Цена биллинга от этого не сильно изменится, а цена решения - да. Но зато будет выбор БД: непойми что забесплатно или нормальная БД за деньги. Каждый будет решать сам.

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

А под оракл компактные базы типа?

_________________
I'm clever. I've got a computer.

Вообще, то что вы предлагаете — это сложно. Разговоры об этом тут были много раз, и обсуждения тоже, гляньте постарее темы.

_________________
I'm clever. I've got a computer.

В оракле практически все можно решить не грохая базу, стандартными средствами. На предыдущей работе была оракловая БД порядка 600Гб. За 5 лет ни разу никаких проблем не возникло.
И с бекапами все гораздо проще. Настроил один раз скрипты полного и инкрементального бекапов с нужной периодичностью для RMAN, поставил в крон и забыл - все бекапится и складывается куда надо без всяких перерывов в работе. Про HA решения типа RAC я и не говорю даже.

Такая ситуация могла бы наблюдаться без innodb_file_per_table
Возможно ранее у вас не было такой настройки в my.cnf, а потом вы ее поставили. до этого этот файл содержал индексы всех таблиц. и он естественно уже не отдает это место

А лицензии оракла не все могут себе позволить


Бекапы делаются у всех кто тут при помощи репликации базы. Думаю slave базу вы можете себе позволить остановить

Хотя лично я ничего против Oracle не имею. Но для данного биллинга он слишком громоздкий как здесь уже обсуждалось. Здесь СУБД используется тупо как хранилище, вся логика работы вынесена в сам биллинг

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Да, непросто. Но есть к чему стремиться. Вот на вскидку то, что лежит на поверхности:
1. DDL. Синтаксис может быть разным. Например при создании новых месячных таблиц.
Но имея на входе имя таблицы, набор полей с их именами и абстрактными типами и тип БД получить нужный DDL не проблема.
2. Встроенные функции. Например NOW() в mysql и SYSDATE в oracle. Тут уже сложнее. Нужно будет пересмотреть их использование и там где без них не обойтись использовать например функции обертки.
3. Автоинкрементные поля и получение последнего id. Вполне можно решить, формализовав работу через API.

По-хорошему надо работать вообще через ORM, хотя бы тонкий. Остальное — от лукового и для больших проектов выливается в колхоз. То что сейчас — механизм "драйверов" JDBC — уж слишком тонкий и как вы верно заметили, на уровне SQL имеет проблемы совместимости, которые опять же почти все решаемы и в рамках того же JDBC, но просто у нас не так и с этим требуется смириться. Чтобы было всё универсально — было бы круто, но почти нереально по определённым причинамъ.

_________________
I'm clever. I've got a computer.

Да это возможно и без innodb_file_per_table, но с innodb_file_per_table сразу заметно что-то не так. Т.к. база ставилась с нуля и все таблицы изначально создавались как innodb, а не делался их ALTER из myiasm. Файл изначально был размером 10Мб и он растет.


А у вас на все железо честно куплены Right to use лицензии, если лицензия это лишь бумажка и железо работает без нее?

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

_________________
I'm clever. I've got a computer.

fixed

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Там вроде как еще проблема с limit-ом . Его нет в oracle.
И почему именно oraсle ? Тут на форуме еще активно postgresql проталкивали, называли его "промышленной субд".

Вот только не надо Oracle! Всё у него возможно и прекрасно, но вот цена! это ужас. А уж их саппорт это отдельная тема...