Re: Выбрать базу данных
Бестолковые разработчики стоят не дорого. Они стоят немеряно. Но в данном случае в стоимость толковых разработчиков придется включить стоимость времени их поиска. Если мы говорим об одиноком разработчике или группе, а не о фирме, которая такими заказами на жизнь зарабатывает. Фирма же возьмет больше денег, поскольку ей надо поддерживать инфраструктуру поиска заказов. Не все фирмы держат толпу алчных менеджеров. Но это скорее к вопросу есть ли жизнь за мкадом?. Впрочем, есть старая шутка о том, что если дурдом вывернуть наизнанку, так, что те, кто внутри и кто снаружи, поменяются местами, ничего не изменится. Иногда таки оказывается дешевле вложиться в железо, а биллинг иметь какой попало. Впрочем, подозреваю, что в описанном случае все-таки да, дешевле будет его переписать. Ну что такое тыща пользователей? Тысяча пользователей - это немного. А вот гиг оперативки и 3 ГГц двухядерный проц - достаточно. Но об этом успешно забыли. Пора писать учебник Решение задач среднего и крупного бизнеса на ЭВМ Pentium IV. Нет, не поверят. А через два года то же самое можно будет делать на КПК. Только некому.
Re: Выбрать базу данных
Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 14 Nov 2007
10:34:51 +0300:
AL ИМХО за десятую часть цены сановского сториджа и сервера можно нанять
AL толкового разработчика (или группу), который напишет вам нормальный
биллинг.
Не скажи. Толковые разработчики стоят дорого.
AP Не так. Стоят дорого бестолковые разработчики.
Бестолковые разработчики стоят не дорого. Они стоят немеряно. Но в
данном случае в стоимость толковых разработчиков придется включить
стоимость времени их поиска. Если мы говорим об одиноком разработчике
или группе, а не о фирме, которая такими заказами на жизнь
зарабатывает. Фирма же возьмет больше денег, поскольку ей надо
поддерживать инфраструктуру поиска заказов.
Иногда таки оказывается дешевле вложиться в железо, а биллинг иметь
какой попало. Впрочем, подозреваю, что в описанном случае все-таки да,
дешевле будет его переписать. Ну что такое тыща пользователей?
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
Victor Wagner в [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 14 Nov 2007
12:31:54 +0300:
Бестолковые разработчики стоят не дорого. Они стоят немеряно. Но в
данном случае в стоимость толковых разработчиков придется включить
стоимость времени их поиска. Если мы говорим об одиноком разработчике
или группе, а не о фирме, которая такими заказами на жизнь
зарабатывает. Фирма же возьмет больше денег, поскольку ей надо
поддерживать инфраструктуру поиска заказов.
AP Не все фирмы держат толпу алчных менеджеров. Но это скорее к
AP вопросу есть ли жизнь за мкадом?. Впрочем, есть старая шутка о
AP том, что если дурдом вывернуть наизнанку, так, что те, кто внутри
AP и кто снаружи, поменяются местами, ничего не изменится.
При чем тут толпа алчных менеджеров? Зарплату толковым разработчикам
платить надо регулярно. И немалую. И грузить интересной работой. А то
разбегутся. Для этого надо обеспечивать достаточно равномерный поток
интересных заказов. Это сложно.
Иногда таки оказывается дешевле вложиться в железо, а биллинг иметь
какой попало. Впрочем, подозреваю, что в описанном случае все-таки да,
дешевле будет его переписать. Ну что такое тыща пользователей?
AP Тысяча пользователей - это немного. А вот гиг оперативки и 3 ГГц
AP двухядерный проц - достаточно. Но об этом успешно забыли. Пора
AP писать учебник Решение задач среднего и крупного бизнеса на ЭВМ
AP Pentium IV. Нет, не поверят. А через два года то же самое можно
AP будет делать на КПК. Только некому.
Немного, да. И я полагаю, что могу при своей квалификации за два-три
месяца, включая предварительную и окончательную подстройку под
требования и тестирование, написать биллинг, который будет в этой позе
работать (и не факт, что мне для этого потребуется постгрес, очень может
быть, что хватит sqlite, а то и вообще без SQL обойдусь, реляционная
база - не единственный способ сделать дурацкий поиск). Но нанять меня
на эту работу - задача весьма нетривиальная. Потому что постоянная
работа у меня уже есть, мне за нее зарплату уже платят, и хотят, чтобы я
за эту зарплату именно эту работу делал. А время у меня только одно.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Intel - тоже Сильмарилл. Только сделанный не так...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Wednesday 14 November 2007 13:00:55 Victor Wagner написал(а): Тысяча пользователей - это немного. А вот гиг оперативки и 3 ГГц двухядерный проц - достаточно. Но об этом успешно забыли. Пора писать учебник Решение задач среднего и крупного бизнеса на ЭВМ Pentium IV. Нет, не поверят. А через два года то же самое можно будет делать на КПК. Только некому. Ну почему некому? Люди, которые 15 лет назад обрабатывали растры 25000x15000 на 486SX еще живы и даже не на пенсии. Согласен, но вы лично будете разработкой билинга заниматься? Сомневаюсь. Полагаю, что и ваши коллеги не будут. Благо и без того есть чем заняться и безработица не грозит. И это правильно. А вот что тот, кто ищет работу, не может ее нормально сделать, это неправильно. P.S. Насчет растров, кстати говоря, - в японских навигашках придуман замечательный формат KIWI, из которого отрисовка идет великолепно (конечно, так называемый физический формат хранения, конечно, квадродерево). А разрешение карты, например, Токио, равно 2 см и на бортовом компе все быстро работает (при том, что машина движется). Базовая документация даже на английском есть (на японском больше, но я не читал, увы, образования не хватает). Но почему-то в настольном софте для навигации все тормозит и просвета не видно (вообще-то KIWI трехмерку хранит, но это для нас лишь мечта). А люди, которые 15 лет назад... работали по какой форме допуска? Из публикаций на русском языке окромя теоретических работ 80-х годов об использовании квадродеревьев для хранения растров мне ничего не припоминается. Наверно, японский пора учить. Пока в стране интернет не запретили.
Re: Выбрать базу данных
Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 14 Nov 2007
13:37:23 +0300:
Тысяча пользователей - это немного. А вот гиг оперативки и 3 ГГц
двухядерный проц - достаточно. Но об этом успешно забыли. Пора
писать учебник Решение задач среднего и крупного бизнеса на ЭВМ
Pentium IV. Нет, не поверят. А через два года то же самое можно
будет делать на КПК. Только некому.
Ну почему некому? Люди, которые 15 лет назад обрабатывали растры
25000x15000 на 486SX еще живы и даже не на пенсии.
AP Согласен, но вы лично будете разработкой билинга заниматься?
AP Сомневаюсь. Полагаю, что и ваши коллеги не будут. Благо и без того
AP есть чем заняться и безработица не грозит. И это правильно. А вот
AP что тот, кто ищет работу, не может ее нормально сделать, это
AP неправильно.
Так потому и ищет, что не может нормально сделать :-)
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Погода опять приняла форму колбасы
(С)энта
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Max V. Kotov [EMAIL PROTECTED] wrote: Alexey Pechnikov wrote: В сообщении от Monday 12 November 2007 12:14:26 Max V. Kotov написал(а): Alexey Pechnikov wrote: Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно. Какие конкретно? Количество одновременных пользователей, число запросов в секунду, метод подключения к базе (на java, наверно, раз речь идет о серваке ibm и работе с oracle), тип задач, соотношение запросов insert/update/select. Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. Хмм.. А можно понитересоваться - что там такого на эту тысячу пользователей пишеться в таких об'емах? Каждый ip пакет чтоль ? При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Мдя. Я например вообще не вижу смысла что-то считать за весь месяц. Если только прочент от продаж диллерам, да и тот - можно посуточно считать. А платный биллинг - тупо надувать, раскладывая готовые данные в те места, где он их ищет. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака. Смотря какой LSI. Хотя, поменять его на 3ware - наверное даст прирост. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Andrey Lyubimets - debian-russian@lists.debian.org @ Wed, 14 Nov 2007
09:58:48 +0600:
У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По
началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4
двухядерных камня, 8Гб оперативки.
AL Ёкарный бабай! А на SCSI диски денег не хватило?!
В итоге часть процедур переработали+оптимизировали часть селектов и ко
всему прочему вынуждены переползать на SUN сервера. Так что если база
действительно серьёзная, думаю, вопрос не в выборе базы данных.
AL [skip]
Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90
- инсерты в схему + процедуры их обработки. База обсчитывает телематические
услуги ~1000 пользователей.
При обработке данных за месяц (билинговании) возникают как раз те проблемы,
от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С
половины суток это время снизили до 3х часов примерно.
Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5,
аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC
интерфейсом и сановского сервака.
AL ИМХО за десятую часть цены сановского сториджа и сервера можно нанять
AL толкового разработчика (или группу), который напишет вам нормальный
биллинг.
Не скажи. Толковые разработчики стоят дорого.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Лень оправдывает средства
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Wednesday 14 November 2007 10:14:01 Artem Chuprina написал(а): AL ИМХО за десятую часть цены сановского сториджа и сервера можно нанять AL толкового разработчика (или группу), который напишет вам нормальный биллинг. Не скажи. Толковые разработчики стоят дорого. Не так. Стоят дорого бестолковые разработчики. Такие, из-за которых потом приходится непрерывно наращивать мощности железа. Зато на форумах, посвященных СУБД, постоянно идут обсуждения - зачем разработчику знать физику с математикой, да и вообще мол образование не нужно. Точно говорит Задорнов, не Азия мы и не Европа, мы Азиопа...
Re: Выбрать базу данных
Alexey Pechnikov wrote: Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно. Какие конкретно? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Monday 12 November 2007 12:14:26 Max V. Kotov написал(а): Alexey Pechnikov wrote: Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно. Какие конкретно? Количество одновременных пользователей, число запросов в секунду, метод подключения к базе (на java, наверно, раз речь идет о серваке ibm и работе с oracle), тип задач, соотношение запросов insert/update/select.
Re: Выбрать базу данных
Alexey Pechnikov wrote: В сообщении от Monday 12 November 2007 12:14:26 Max V. Kotov написал(а): Alexey Pechnikov wrote: Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно. Какие конкретно? Количество одновременных пользователей, число запросов в секунду, метод подключения к базе (на java, наверно, раз речь идет о серваке ibm и работе с oracle), тип задач, соотношение запросов insert/update/select. Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака. Понятно. Я от подобных проблем ушел путем использования материализованных видов - обработка данных происходит непосредственно при их вставке, что позволяет в любой момент получить итоговые данные. В оракле материализованные виды есть из коробки, в постгресе подобную функциональность можно самому написать. Если возникают проблемы с производительностью при вставке, можно выполнять пакетную обработку (небольших наборов данных) в моменты простоя системы. А считать все за один раз единожды в месяц - абсолютно неэффективное разбазаривание ресурсов. Скажем, расчет идет 3 часа, запускается раз в месяц, эффективность использования ресурсов около 1/4 процента.
Re: Выбрать базу данных
Alexey Pechnikov wrote: Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака. Понятно. Я от подобных проблем ушел путем использования материализованных видов - обработка данных происходит непосредственно при их вставке, что позволяет в любой момент получить итоговые данные. В оракле материализованные виды есть из коробки, в постгресе подобную функциональность можно самому написать. Если возникают проблемы с производительностью при вставке, можно выполнять пакетную обработку (небольших наборов данных) в моменты простоя системы. А считать все за один раз единожды в месяц - абсолютно неэффективное разбазаривание ресурсов. Скажем, расчет идет 3 часа, запускается раз в месяц, эффективность использования ресурсов около 1/4 процента. Ну это уже минусы нашей биллинговой системы. Переписать её по другому возможности нет. Нет у неё такого функционала. Да и суппорта такими переделками лишиться можно. Жаль, но вот такие недостатки. Плюсом биллинг не умеет писать логи размером 2Гб. Не понимает SIGHUP и отваливается если один из логфайлов забит. Ротейта предусмотрено не было, ротейтим логротейтом с параметрами size, prerotate, postrotate... Уж как есть. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Monday 12 November 2007 17:43:58 Max V. Kotov написал(а): Ну это уже минусы нашей биллинговой системы. Переписать её по другому возможности нет. Нет у неё такого функционала. Да и суппорта такими переделками лишиться можно. Жаль, но вот такие недостатки. Плюсом биллинг не умеет писать логи размером 2Гб. Не понимает SIGHUP и отваливается если один из логфайлов забит. Ротейта предусмотрено не было, ротейтим логротейтом с параметрами size, prerotate, postrotate... Уж как есть. Понятно. Имхо, достаточно взять постгрес 8.1 и пентиум Д с парой гиг памяти для этой задачи, плюс сделать нормальную схему данных. Но оракл это конечно круче... А наращивать железо невыгодно, поскольку масштабируется нелинейно и однажды вам понадобится кластер и свой дата-центр на базе в 100 гигабайт. Впрочем, вряд ли у вас есть варианты, если уже куплен такой билинг. P.S. За инфу спасибо. Сам уже не раз сталкивался, что заказчики хотят слышать знакомые слова и на оракле систему продать намного легче, чем на постгресе (притом, что работать может отвратительно, но это, увы, никто не оценивает, смотрят только на названия). Серьезный плюс у оракла - сформировавшееся комьюнити и соответственно доступность информации, в т.ч. на русском языке. А с другой стороны, чтобы спроектировать хорошую схему БД, надо читать теоретические работы, а не документацию на конкретную СУБД. Так что для серьезных задач постгрес имеет огромное преимущество - гибкость. Думайте сами, решайте сами...
Re: Выбрать базу данных
Max V. Kotov wrote: Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака. неужели это настолько узкое место? изменения в дисковой подсистеме на scsi/sas 15k, raid-адаптер с батарейкой и кучей памяти (256 или 512Мб), raid 10 и по необходимости дисков побольше - должны поднять производительность в разы за существенно меньшие деньги. sata диски вообще не рулят по соотношению цена/качество на базах данных ;) ps: хотя если деньги есть... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Игорь Чумак wrote: Tochenyk Oleg пишет: Ну у людей прирост 1 гб в месяц... значит террабайт где-то за 8 лет набежит... А про данный случай было сказано: а) железо новое не советовать б) пересматривать схему базы данных не хотят Ну значит остается только смена субд. И какая СУБД будет ворочать многогигабайтные базы за приемлемое время на P3/512M? PS: До терабайта база вряд ли доживёт. Сколько уже лет тому нещасному серверу? Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных. А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно.
Re: Выбрать базу данных
Tochenyk Oleg пишет: Ну у людей прирост 1 гб в месяц... значит террабайт где-то за 8 лет набежит... А про данный случай было сказано: а) железо новое не советовать б) пересматривать схему базы данных не хотят Ну значит остается только смена субд. И какая СУБД будет ворочать многогигабайтные базы за приемлемое время на P3/512M? PS: До терабайта база вряд ли доживёт. Сколько уже лет тому нещасному серверу? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Friday 09 November 2007 12:16:44 Игорь Чумак написал(а): И какая СУБД будет ворочать многогигабайтные базы за приемлемое время на P3/512M? PS: До терабайта база вряд ли доживёт. Сколько уже лет тому нещасному серверу? PostgreSQL. На целероне 2.6 с 256 памяти и древним 40 гиг винтом ворочает 10-гиговую базу. Полсотни пользователей, работает шустро. Большая часть отчетов оптимизирована и строится по предварительным выборкам, но некоторые отчеты часто меняются и потому оптимизировать смысла нет. Когда кто-нибудь начинает строить такие отчеты _по всему_ массиву данных, серьезно задумывается, но тут уж ничего не поделаешь, да и надо это раз в месяц. P.S. P3/512M это нормальное железо, если читать литературу по оптимизации и алгоритмике, а не рекламу.
Re: Выбрать базу данных
Alexey Pechnikov пишет: В сообщении от Friday 09 November 2007 12:16:44 Игорь Чумак написал(а): И какая СУБД будет ворочать многогигабайтные базы за приемлемое время на P3/512M? PS: До терабайта база вряд ли доживёт. Сколько уже лет тому нещасному серверу? PostgreSQL. На целероне 2.6 с 256 памяти и древним 40 гиг винтом ворочает 10-гиговую базу. Полсотни пользователей, работает шустро. Большая часть отчетов оптимизирована и строится по предварительным выборкам, но некоторые отчеты часто меняются и потому оптимизировать смысла нет. Когда кто-нибудь начинает строить такие отчеты _по всему_ массиву данных, серьезно задумывается, но тут уж ничего не поделаешь, да и надо это раз в месяц. Что-то мне подсказывает, что у спрашивающего ситуация несколько иная. P.S. P3/512M это нормальное железо, Производилось до 2003года. Где его можно купить (не бу) в 2007 году? Сколько ещё оно протянет? если читать литературу по оптимизации и алгоритмике, а не рекламу. Ушол читать литературу ;) PS: не верю ,что при тех же условиях (схема данных, размер базы, железо) postgresql в 100раз быстрее mysql. Но ставить эксперимент мне лень ;) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
P.S. P3/512M это нормальное железо, Производилось до 2003года. Где его можно купить (не бу) в 2007 году? Сколько ещё оно протянет? Когда беру новое железо, смотрю на пентиум Д и коре2дуо. Однако это не значит, что мне такая производительность требуется. Вот разве что на десктопе - всякие мозиллы и проч. ресурсов жрут почище нагруженного сервера. если читать литературу по оптимизации и алгоритмике, а не рекламу. Ушол читать литературу ;) PS: не верю ,что при тех же условиях (схема данных, размер базы, железо) postgresql в 100раз быстрее mysql. Но ставить эксперимент мне лень ;) В постгресе у меня несколько сот килобайт pltcl кода зашито. Для мускуля пришлось бы это или на сях писать (что нереально, ибо соотношение тиклевского кода к сишному 1:10, проверено), или выносить на уровень выше, что приведет к потере производительности как минимум на порядкок (в 10 раз). А еще в постгресе можно пользоваться партишионированием таблиц, кластеризацией, множеством схем (schema), временными таблицами и видами, предвыборками в пользовательских схемах и т.п. Плюс хороший сервер приложений (AOL Web Server) с пулом подключений к БД и кэшами. На вышеуказанном железе 100 - 300 одновременных пользователей, плюс запросы аякс-модулей интерфейса от каждой открытой страницы раз в 5 секунд - и все это при нагрузке процессора сервера около 20% не хотите? Будете собирать кластер из десятка машин на коре2дуо для решения аналогичной задачи на мускуле, пришлите фото, порадуйте :-)
Re: Выбрать базу данных
Ну у людей прирост 1 гб в месяц... значит террабайт где-то за 8 лет набежит... А про данный случай было сказано: а) железо новое не советовать б) пересматривать схему базы данных не хотят Ну значит остается только смена субд. On Wed, 2007-11-07 at 17:57 +0300, Alexey Pechnikov wrote: В сообщении от Wednesday 07 November 2007 17:43:20 Tochenyk Oleg написал(а): Лично я считаю что оракл лучше постгрее (на текущий момент времени), опять же оракл работает, а загрузить данные для отправки багрепортов, ну в свободное от работы время возможно это и можно сделать, но если задача стоит чтобы работало, то 50К зелени и оно таки будет работать. Опять же мы отвлекаемся от тему треда. Но по моему опять же времени лучше тот софт который работает с минимумом проблем для пользователя, а платный он или нет, это уже следующий вопрос. Постгрес 8.1 и 8.2 работают. Версия 8.3 сейчас в статусе беты, но там добавлено много возможностей, которые могут кому-то приглянуться. Для базы размером в несколько гиг постгрес объективно лучше оракла, поскольку способен управляться с этой базой на железе, на котором оракл и не запустится. Минимум проблем включает в себя и минимум аппаратных требований. Для базы более терабайта вы (возможно) правы, но в данном случае про оракл вспоминать не стоило. -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: Если слово ПОТЕНЦИЯ прочитать наоборот - получится ЯИЦ НЕТ, ОП!... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Wednesday 07 November 2007 17:43:20 Tochenyk Oleg написал(а): Лично я считаю что оракл лучше постгрее (на текущий момент времени), опять же оракл работает, а загрузить данные для отправки багрепортов, ну в свободное от работы время возможно это и можно сделать, но если задача стоит чтобы работало, то 50К зелени и оно таки будет работать. Опять же мы отвлекаемся от тему треда. Но по моему опять же времени лучше тот софт который работает с минимумом проблем для пользователя, а платный он или нет, это уже следующий вопрос. Постгрес 8.1 и 8.2 работают. Версия 8.3 сейчас в статусе беты, но там добавлено много возможностей, которые могут кому-то приглянуться. Для базы размером в несколько гиг постгрес объективно лучше оракла, поскольку способен управляться с этой базой на железе, на котором оракл и не запустится. Минимум проблем включает в себя и минимум аппаратных требований. Для базы более терабайта вы (возможно) правы, но в данном случае про оракл вспоминать не стоило.
Re: Выбрать базу данных
Лично я считаю что оракл лучше постгрее (на текущий момент времени), опять же оракл работает, а загрузить данные для отправки багрепортов, ну в свободное от работы время возможно это и можно сделать, но если задача стоит чтобы работало, то 50К зелени и оно таки будет работать. Опять же мы отвлекаемся от тему треда. Но по моему опять же времени лучше тот софт который работает с минимумом проблем для пользователя, а платный он или нет, это уже следующий вопрос. On Wed, 2007-11-07 at 17:09 +0300, Alexey Pechnikov wrote: В сообщении от Wednesday 07 November 2007 17:04:48 Tochenyk Oleg написал(а): А в чем проблема... попробовать вполне можно, если это то что нужно то уже можно вести разговор о деньгах. Но опять же, я лично советую пересмотреть схему базы данных. Зачем пробовать оракл? Можно бета-версию постгреса 8.3 потестировать и отчет о багах написать. Или вы тоже считаете, что проприетарный софт лучше открытого? -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: - Всего второй день замужем, а столько долгов накопилось... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
А в чем проблема... попробовать вполне можно, если это то что нужно то уже можно вести разговор о деньгах. Но опять же, я лично советую пересмотреть схему базы данных. On Wed, 2007-11-07 at 16:57 +0300, Alexey Pechnikov wrote: В сообщении от Wednesday 07 November 2007 16:23:28 Alexey Lobanov написал(а): Ну батенька тогда может оракл вам поможет... но это дорого :) Но загрузить и попробовать никто не препятствует. На Дебиан оно встаёт почти без напильника. Вот дела, в рассылке debian-russian теперь проприетарный софт советуют. Причем там, где он и вовсе не нужен. Да еще без подробного рассказа о лицензионной политике оракла. -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: Надпись в 85-89г. г. на втором посту в Одесском арт. училище: И спать хочется, и Родину жалко! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Wednesday 07 November 2007 16:23:28 Alexey Lobanov написал(а): Ну батенька тогда может оракл вам поможет... но это дорого :) Но загрузить и попробовать никто не препятствует. На Дебиан оно встаёт почти без напильника. Вот дела, в рассылке debian-russian теперь проприетарный софт советуют. Причем там, где он и вовсе не нужен. Да еще без подробного рассказа о лицензионной политике оракла.
Re: Выбрать базу данных
В сообщении от Wednesday 07 November 2007 15:16:27 Игорь Чумак написал(а): Vladimir N. Shilov пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Добрый день! какая база данных будет нормально работать при таких бъёмах: таблица порядка 1 гигабайта в месяц, милионы записей. в основном - инсерт, иногда селекты. на mysql и P3/512RAM/SCSI - селекты по 18-20 минут, пробовал разные варианты индексов - без результата. направте на путь истинный... http://postgrestips.blogspot.com/2007/06/blog-post.html Вариант с другим железом не рассматривается? Увеличить аппаратную производительность на 4 порядка (до 2-х - 4-х секунд) или сменить базу данных и перепроектировать приложение - по-моему, выбор очевиден.
Re: Выбрать базу данных
Hello! В сообщении от Wednesday 07 November 2007 18:22:53 вы написали: Ну у людей прирост 1 гб в месяц... значит террабайт где-то за 8 лет набежит... Через 8 лет соотношение сил разных СУБД значительно изменится. Если же верить Стоунбрейкеру, уже пора изучать базы наподобии мнезия (думаю, к тому времени базы указанного объема будут размещаться в оперативке). А про данный случай было сказано: а) железо новое не советовать б) пересматривать схему базы данных не хотят Ну значит остается только смена субд. Ага. Но все же мускуль менять на постгрес логичнее. И заодно готовиться переписать приложение и схему БД. И скорее всего не один раз, пока не получится что-то приемлемое. Best regards, Alexey.
Re: Выбрать базу данных
В сообщении от Wednesday 07 November 2007 17:04:48 Tochenyk Oleg написал(а): А в чем проблема... попробовать вполне можно, если это то что нужно то уже можно вести разговор о деньгах. Но опять же, я лично советую пересмотреть схему базы данных. Зачем пробовать оракл? Можно бета-версию постгреса 8.3 потестировать и отчет о багах написать. Или вы тоже считаете, что проприетарный софт лучше открытого?
Re: Выбрать базу данных
Ну батенька тогда может оракл вам поможет... но это дорого :) ну или вариант с перепроектированием базы данных. On Wed, 2007-11-07 at 13:29 +0200, Vladimir N. Shilov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Добрый день! какая база данных будет нормально работать при таких бъёмах: таблица порядка 1 гигабайта в месяц, милионы записей. в основном - инсерт, иногда селекты. на mysql и P3/512RAM/SCSI - селекты по 18-20 минут, пробовал разные варианты индексов - без результата. направте на путь истинный... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMaGcmOCNXyJeqqgRAmUWAJ4wyldYaRh3b71c3qeOH+qiIw8kRgCg77y+ uJStGhQws+qoQGIIqHQ6DqE= =QzYN -END PGP SIGNATURE- -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: Если ты нашел на счастье подкову, значит кто-то другой откинул копыта... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Да боюсь что просто загрузить и попробовать особой производительности не получите... все таки правильнее смотреть логическую структуру базы данных и пробовать копать с этого направления. On Wed, 2007-11-07 at 16:23 +0300, Alexey Lobanov wrote: 07.11.2007 16:14, Tochenyk Oleg пишет: Ну батенька тогда может оракл вам поможет... но это дорого :) Но загрузить и попробовать никто не препятствует. На Дебиан оно встаёт почти без напильника. А.Л. -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: Как показывает практика, выспаться по-настоящему возможно только в рабочее время, полностью забив на работу... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
07.11.2007 16:14, Tochenyk Oleg пишет: Ну батенька тогда может оракл вам поможет... но это дорого :) Но загрузить и попробовать никто не препятствует. На Дебиан оно встаёт почти без напильника. А.Л. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
Tochenyk Oleg - Alexey Pechnikov @ Wed, 07 Nov 2007 17:22:53 +0200:
TO Ну у людей прирост 1 гб в месяц... значит террабайт где-то за 8 лет
TO набежит...
TO А про данный случай было сказано:
TO а) железо новое не советовать
TO б) пересматривать схему базы данных не хотят
TO Ну значит остается только смена субд.
... или вешаться. Смена субд в такой ситуации, подозреваю, тоже не поможет.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Обновление Windows изменило интуитивно ясный интерфейс Вашего компьютера.
Загрузите обновление интуиции с сайта Microsoft.
(С)энта
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Выбрать базу данных
В сообщении от Wednesday 07 November 2007 16:14:35 Tochenyk Oleg написал(а): Ну батенька тогда может оракл вам поможет... но это дорого :) ну или вариант с перепроектированием базы данных. Для маленькой (гигабайт в месяц) базы это еще и бесполезно. Нужна база с поддержкой логики (триггеры, функции) для пополнения агрегированных таблиц при вставке новых данных. И соответственно, запрос будет не к сырым данным, а к уже обработанным. И плюс нормальная поддержка групповых функций (мускуль в свое время жрал память и проц на таких запросах, наверно, пытался все целиком в оперативку запихнуть и там обрабатывать).
