Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Firebird, Interbase > Firebird есть сомнения на его счет

Автор: B2_Russia 2.10.2005, 20:34

Видел тут программку написанную на Delphi использующую Firebird. Программа оперирует с данными очень больших объемов. Достаточно сказать что одна из таблиц на 120 тыс записей, другая не менее 300 тыс, третья 350 тыс, в процессе работы база постоянно пополняется данными, так как программа должна позволять хранить ранее введенные данные даже если они отменяют старые, чтобы в любой момент можно было ознакомиться с историей их изменения (наполовину бухгалтерия). Вышеобозначенные таблицы являются связанными. Всего 75 таблиц, в каждой приличное наполнение. Каждый месяц программа должна выдавать итоговый результат по клиентам, производить расчет и хранить его. У меня есть сомнения что Firebird способен работать с подобными объемами без сбоев. Наблюдал как выполнение транзакции инициируемой с сетевого ПК привело к тому что она отработала не полностью, часть данных не была пересчитана... Расчет идет порядка 2-3 часов, а то и того больше... Мне эту или подобную программу нужно использовать, я на ее счет сомневаюсь, либо писать все с нуля... Если писать с нуля то Firebird уж точно не буду использовать, тогда что? Oracle - дорого как он сам так и его обслуживание, iBase/firebird не внушает доверия, у меня данных будет гораздо больше... Нужен совет!

Автор: Satana 2.10.2005, 21:25

ну раз такие дела то оптимумом для тебя будет наверное MSSQL + хорошая_мощьная_машинка

Автор: Alex 2.10.2005, 22:13

B2_Russia, указанные вами объемы не очень то и большие. FB справляется с такими объемами, а вот насколько оптимальные запросы вы используете и насколько грамотно у вас организовано хранение данных, раставлены индексы, отключаете ли вы индексы перед добавлением большого числа данных, какими компонентами доступа вы пользуетесь, как вы работаете с транзакциями вот это уже совсем другой вопрос. Если вы не соблюдаете всех этих правил, то вам любая БД будет казаться слабой. Добавлено @ 22:14 На FB есть базы по 80 и более гиг и все великолепно работает

Автор: Alex 2.10.2005, 22:23

Цитата "У нас одна из баз данных содержит таблицу с 32 миллионами строк (записей), в которую ежедневно добавляется от 100 до 150 тысяч записей. Добавление занимает около часа. Эта таблица имеет около 30-ти столбцов, пару индексов, и несколько триггеров, срабатывающих на insert. Высокая производительность IB на таком объеме данных нас вполне устраивает."

Автор: LSD 2.10.2005, 22:36

Alex А откуда цитата? Можно поподробней о структуре таблиц, железе, количестве пользователей и версии БД?

Автор: Alex 2.10.2005, 22:37

http://ibase.ru/devinfo/people.htm Добавлено @ 22:41 У самого есть проект, в котором каждый день добавляется по 500 записей только в автоматическом режиме, плюс ручной ввод. Работает минимум 3 пользователя одновременно. в таблице около 50 колонок. Недавно был прицендент, когда нужно было по этой многострадальной таблице составить одну замысловатую выборку. Напарник написал запрос с виду совершенно правильный. Запрос обрабатывался 15 минут, после небольшого изучения документации и применения немного другого метода написания выборки время выполнения сократилось до 8 секунд.

Автор: B2_Russia 2.10.2005, 22:43

Santa, машинка не проблема... Alex, дело в том, что программа не моя, писал ее не я, моя задача оценить насколько она пригодна для моей организации... БД там примерно на 2,5 Гб, но при обсчете итоговых месячных данных используется большое кол-во параметров хранящихся в разных таблицах, они очень плотно связаны между собой. Программу оставляют на ночь для завершения просчета... Сам в коде не капался, да и не особо я разбираюсь в iBase/firebird да и вообще моя пока только с mySQL только плотно работал... Так что уровень немного не тот... Возможно код криво написан, не оптимизирована БД... Очень меня настораживает тот факт что считает долго и был сбой при отработке транзакции с др. ПК (не с сервера). Транзакция отработала частично... Добавлено @ 22:45 Понимаешь еще вот ты говоришь отключение индексов... Нам нужно было добавить в их базу мои данные, так вот добавляли они их без того самого отключения индексов, а после просто сделали backup/restore. Время ушло уйма...

Автор: Alex 2.10.2005, 22:49

Цитата(B2_Russia @ 2.10.2005, 23:43) Транзакция отработала частично... первый раз о таком слышу. скорей всего, человек для вставки большого числа данных выполняет каждый insert в рамках отдельной транзакции, тогда это в разы повышает время на добавление Цитата(B2_Russia @ 2.10.2005, 23:43) Сам в коде не капался, да и не особо я разбираюсь в iBase/firebird да и вообще моя пока только с mySQL только плотно работал... Без обид, но сравнивать mysql и FB это уже слишком Добавлено @ 22:52 Цитата(B2_Russia @ 2.10.2005, 23:43) Понимаешь еще вот ты говоришь отключение индексов... Нам нужно было добавить в их базу мои данные, так вот добавляли они их без того самого отключения индексов, а после просто сделали backup/restore. Время ушло уйма... что-то у вас небольшая каша в голове. Просто при добавлении записи в таблицу БД пересчитывает все активные индексы для таблицы. Когда добавляется большое число записей, что бы не дергать пересчет индексов после добавления каждой записи их временно диактивируют. backup/restore здесь совершенно не при чем. Добавлено @ 22:53 Если уж вас гложат такие сомнения, то скинте мне тестовый вариант базы, посмотрим, что и как у вас там сделано.

Автор: B2_Russia 2.10.2005, 22:53

Alex, ibase.ru сделан на шаблоне от Macromedia ;) Но сайт неплох...

Автор: Alex 2.10.2005, 22:57

Цитата(B2_Russia @ 2.10.2005, 23:53) Alex, ibase.ru сделан на шаблоне от Macromedia ;) Но сайт неплох... мне как-то все равно на чем сделан сайт, но люди знают о чем они говорят. Почитай найдешь много интересного для себя

Автор: B2_Russia 2.10.2005, 23:02

Цитата(Alex @ 2.10.2005, 22:49) Без обид, но сравнивать mysql и FB это уже слишком  Так вот далее по тексту я и даю понять что уровень не тот... Я знаю что они не сравнимы Цитата(Alex @ 2.10.2005, 22:49) что-то у вас небольшая каша в голове. Каша есть... IB не моя стихия, знания БД поверхностны, поэтому и спрашиваю Цитата(Alex @ 2.10.2005, 22:49) Если уж вас гложат такие сомнения, то скинте мне тестовый вариант базы, посмотрим, что и как у вас там сделано. Рад бы, да только не выдали мне ни программу ни БД, нужно принять решение приобретать ее или нет... Но то что я видел меня повергло в шок, программисты написавшие программу 1,5 суток искали причину сбоя греша на !железо! В конце-концов дали вышеупомянутую ремарку... Мое же положение практически безвыходное, через 1,5 месяца нужен результат работы программы, нормальные аналоги стоят очень дорого, заказать разработку - нет времени, использовать этот продукт (впечатление такое что "сделан на коленке") не могу позволить, сбоит при удобном случае, многое зашито в код и не настраивается... Добавлено @ 23:03 Цитата(Alex @ 2.10.2005, 22:57) мне как-то все равно на чем сделан сайт, но люди знают о чем они говорят. Почитай найдешь много интересного для себя Без обид, я просто увлекаюсь разработкой сайтов, но при этом знаю что сайт начинается с контента ;)

Автор: Alex 2.10.2005, 23:05

Цитата(B2_Russia @ 3.10.2005, 00:02) Рад бы, да только не выдали мне ни программу ни БД, нужно принять решение приобретать ее или нет... Но то что я видел меня повергло в шок, программисты написавшие программу 1,5 суток искали причину сбоя греша на !железо! В конце-концов дали вышеупомянутую ремарку... Мое же положение практически безвыходное, через 1,5 месяца нужен результат работы программы, нормальные аналоги стоят очень дорого, заказать разработку - нет времени, использовать этот продукт (впечатление такое что "сделан на коленке") не могу позволить, сбоит при удобном случае, многое зашито в код и не настраивается... Тогда все причины сбоев ищите в клиенском приложении (точнее в людях его писавших), а БД с этой точки зрения справляется с такими объемами данных в легкую

Автор: B2_Russia 2.10.2005, 23:07

Самое интересное что они обвинили в сбое Firebird! Ни одного слова об ошибке в программе, как будто боги ее писали, девственный код... - Не может быть! - Да так и есть! Вобщем как бы не приобрести кота в мешке!

Автор: Alex 2.10.2005, 23:08

Цитата(B2_Russia @ 3.10.2005, 00:02) Но то что я видел меня повергло в шок, программисты написавшие программу 1,5 суток искали причину сбоя греша на !железо! Бред полный. FB работает на таком антиквариате, что многие и забыли уже как это выглядит Добавлено @ 23:09 Цитата(B2_Russia @ 3.10.2005, 00:07) Самое интересное что они обвинили в сбое Firebird! это что-то новенькое... Добавлено @ 23:14 По хорошему заказ разработки на стороне насколько я понял бухгалтерской программы это месяца 3 работы со всеми отладками, при условии, что вы точно знаете чего вы хотите, а если дадите человеку пример программы и укажите, что вас не устраивает, то может и быстрее.

Автор: B2_Russia 2.10.2005, 23:32

Программа достаточно сложная... Много нюансов, сложности с подготовкой форматов входных данных они могут меняться, то есть из одной орг-ии такая стр-ра таблицы из другой другая... А объемы большие и все нужно загонять в БД... Расчеты зависят от многих факторов, живая динамика этих факторов (они постоянно меняются)... Конечно, на первое время может и затычка вроде вышеупомянутой программы сойдет, но вопрос какой ценой?

Автор: Alex 2.10.2005, 23:50

Мой вам совет: пишите ТЗ и ищите хорошего программиста

Автор: SergeBS 6.10.2005, 15:55

Alex Цитата Без обид, но сравнивать mysql и FB это уже слишком Немного не понимаю, поэтому если мне ткнут пальцем в приципиальную разницу, буду очень рад. Или в url, где описана эта разница. Мне как раз легкий/бесплатный и т.п. серверок нужен, но FB с его нелюбовью к автоинкрементным полям немного неприятен.

Автор: Alex 6.10.2005, 16:01

Цитата(SergeBS @ 6.10.2005, 16:55) Немного не понимаю, поэтому если мне ткнут пальцем в приципиальную разницу, буду очень рад Нет, тригеров, хранимых процедур, представлений, занимает много места, не устойчив к большому числу данных и т.д. и т.п. Цитата(SergeBS @ 6.10.2005, 16:55) B с его нелюбовью к автоинкрементным полям немного неприятен. Какие проблемы? Генератор и 1 тригер

Автор: SergeBS 12.10.2005, 19:11

Alex Цитата Нет тригеров, хранимых процедур, представлений, занимает много места, не устойчив к большому числу данных и т.д. и т.п. Отстал от жизни . mySQL 5.04: Цитата Chapter 19. Stored Procedures and Functions 19.1. Stored Procedures and the Grant Tables 19.2. Stored Procedure Syntax 19.2.1. CREATE PROCEDURE and CREATE FUNCTION 19.2.2. ALTER PROCEDURE and ALTER FUNCTION 19.2.3. DROP PROCEDURE and DROP FUNCTION Chapter 20. Triggers 20.1. CREATE TRIGGER Syntax 20.2. DROP TRIGGER Syntax 20.3. Using Triggers 21.2. CREATE VIEW Syntax Место при нынешних машинах - несущественно. Насчет большого количества данных - есть примеры или личный опыт? URL? Цитата Какие проблемы? Генератор и 1 тригер Угу. И так 100 раз подряд. Плюс обрамление на клиенте. Может я назойлив, но мне очень надо их сравнить. И выбрать на что падать. А знаю я оба продукта одинаково плохо - ну не назвать же хорошим знанием учебную задачку с 5 табличками без триггеров, хранимок и т.п. Хочется нечто, чтобы поменьше руками переделывать (переезд с MS SQL по соображениям лицензионности, кроссплатформенности и т.п.).

Автор: Alex 12.10.2005, 20:44

Цитата(SergeBS @ 12.10.2005, 20:11) Насчет большого количества данных - есть примеры или личный опыт? URL? Личный опыт. Цитата(SergeBS @ 12.10.2005, 20:11) Плюс обрамление на клиенте. Зачем на клиенте? Цитата(SergeBS @ 12.10.2005, 20:11) И так 100 раз подряд 1 генератор на все таблицы кто мешает делать? Плюс во 2 версии будет можно ставить однин тригер на несколько таблиц Цитата(SergeBS @ 12.10.2005, 20:11) Может я назойлив, но мне очень надо их сравнить. И выбрать на что падать. А знаю я оба продукта одинаково плохо - ну не назвать же хорошим знанием учебную задачку с 5 табличками без триггеров, хранимок и т.п. Хочется нечто, чтобы поменьше руками переделывать (переезд с MS SQL по соображениям лицензионности, кроссплатформенности и т.п.). Развитый sql я думаю если в уходите с MsSql, то прелись оператора case и ряда других в select'ет вам объяснять не нужно. Наличие замечательных компонентов для доступа FIbPlus (вы забудите, что такое тригеры для задания уникальных значений в поле и т.д.) наличие драйвера доступа для .Net, про UDF функции забывать тоже не стоит (благодаря им в обще практически не остается задач, которые нельзя было бы решить на стороне сервера) Да и просто сама по себе серьезная база. Добавлено @ 20:45 Честно, я в обще плохо понимаю как у людей после MsSql голова поворачивается в сторону MySql

Автор: SergeBS 14.10.2005, 13:16

Alex Цитата Цитата (SergeBS @ 12.10.2005, 20:11) Плюс обрамление на клиенте. Зачем на клиенте? У меня база с автоинкрементными полями. В MS SQL все просто: добавил запись, перечитал - это поле получил (ADO). А FireBird так не умеет. Т.е. - слетать с ADO - под сотню компонент переделывать. Не слетать - переделывать логику работы. И то и другое - неприятно. Ну ленивый я . Знаю что придется переделывать, но хочется чтобы поменьше. Цитата Честно, я в обще плохо понимаю как у людей после MsSql голова поворачивается в сторону MySql Если отдельные "представители потенциальных заказчиков" Word поставить не могут, то голова поворачивается в очень разные стороны. Мотаться по всей области из-за их безрукости - не хочется. А если все-таки провайдеры какие-никакие в каждом (практически) райцентре есть, то про mySQL они по крайней мере слышали. Все жить проще (не меня трясти будут после своей очередной криворукости).

Автор: Alex 14.10.2005, 14:45

Цитата(SergeBS @ 14.10.2005, 14:16) Если отдельные "представители потенциальных заказчиков" Word поставить не могут, то голова поворачивается в очень разные стороны. Мотаться по всей области из-за их безрукости - не хочется. А если все-таки провайдеры какие-никакие в каждом (практически) райцентре есть, то про mySQL они по крайней мере слышали. Все жить проще (не меня трясти будут после своей очередной криворукости). Тогда тем болие возьми FB. настроек минимум (точнее в обще нет на начальном этапе) Добавлено @ 14:47 Цитата(SergeBS @ 14.10.2005, 14:16) У меня база с автоинкрементными полями. В MS SQL все просто: добавил запись, перечитал - это поле получил (ADO). А FireBird так не умеет. Т.е. - слетать с ADO - под сотню компонент переделывать. Не слетать - переделывать логику работы. И то и другое - неприятно. Ну ленивый я . Знаю что придется переделывать, но хочется чтобы поменьше. Если автоинкрементные поля использовались для создания уникальных номеров записей, то возьми FIbPlus и ты забудишь, что это в обще такое все сделают за тебя, только название генератора и поле в таблице будишь указывать

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)