Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.12.25;
Скачать: [xml.tar.bz2];

Вниз

А какое железо по базу?   Найти похожие ветки 

 
step[B.M.]   (2005-11-03 00:49) [0]

база, сервер Firebird
115 таблиц (от мелких справочников, до 2 млн. записей некоторые)
туча триггеров, функций, процедур UDF и прочих прелестей Firebird.

Сейчас оно крутится на WIN32 (celeron 2.4/256RAM/HDD ATA 8Mb cash) но планирую мигрировать на FreeBSD
(давеча UDF переписываю под Фришку)

А что, братухи, посоветуете с железа на эту базу.
В железе мало разбираюсь.
Есть 1500$ зеленью. Директор больше не даст. Это и так вершина его понимания нужности принципиально другого железа.


 
sniknik ©   (2005-11-03 01:38) [1]

мне бы твои проблемы... 2 милиона записей... (неделя/две работы магазина, сумма чековых лент с 20 касс...) а у тебя это всего? счастливый.

любой комп современный ~ за 300$, и sql сервер (MSDE), хватит "с головой". даже не стоит выделеть его в отдельный сервер, можно секретаршу посадить пусть в пасьянс играет/документы распечатывает. главное ей прав админских не давать и заставлять пораньше приходить (чтобы самым первым этот комп включался)


 
step[B.M.]   (2005-11-03 02:10) [2]

to sniknik
угу. давайте-давайте,
у меня 7 человек сидят, круглосуточно, и данные ворочаются по 150 тис. в день (insert/delete) по основным таблицам, и полей в них не мало.
И плюс в запросах надо по 15-20 тис виводить, да не просто select * from
а залезать в процедуры до третьего колена.

А простой в 5-10 секунд при открытии запроса, при интенсивной работе (а она именно такая)  вываливается в часы ожидания.

И мо моему, ваши "стебания"

>любой комп ~ за 300$,
>sql сервер (MSDE), хватит "с головой".
>можно секретаршу
>пасьянс играет/документы распечатывает.

без повода.


 
step[B.M.]   (2005-11-03 02:21) [3]

Хорошо, поставлю вопрос по другому.
==============================
Братухи, а у кого какое железо где водятся РСУБД больше 2 миллиона.

железо
- стоимотью 300$,
- возле которого ходит секретарша (молчу о том что она за ним сидит),
- на кототом установлен WIN32 (пасьянс в т.ч.)
не прелдагать :-)))


 
sniknik ©   (2005-11-03 02:47) [4]

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

отдельностоящий супер крей под базу в 2 лимона записей тебе уж точно не посоветуют. ;о))

да, скорее всего посоветуют чтонибудь помощнее чем я, но только на "про запас" и еще потому, что глупо покупать моломощный комп только потому что он "тянет" задачу сейчас, если можно купить всего на 100$льник дороже в 2 раза круче, и не думать о потом. (т.е. выгоды более хозяйственного/меркантильного плана чем расчет мощьностей под непосильную задачу ;))


 
Карелин Артем ©   (2005-11-03 06:19) [5]

Зависит от того, как сделана база. У меня, например, программа с 600 000 записей в одной из таблиц и примерно полусотней таблиц в базе  работает на вводе данных очень четко даже на AMD K6-266.
На отчете жестоком (раз в полгода формируется), для формирования которого требуется выполнить полтысячи нехилых запросов к базе, лучше сделать харакири.
Ну а про рекомендации.... Вряд ли можно что-то нестандартное придумать.
Проц Intel, не Celeron, c большим кэшем. Памяти 512 минимум, причем 2-мя планками. Дисковый массив на SATA. Видюха проще некуда.
Короче стандартный комп за такие деньги.
P.S. Проиндексировать системные таблицы обязательно.


 
erika ©   (2005-11-03 07:40) [6]

xeon 2000/ 1  Гб/ HHD 120 raid... ничего летает


 
Desdechado ©   (2005-11-03 11:49) [7]

автору
Ты лучше скажи, чем тебя существующая кофигурация не устраивает? В принципе она должна работать вполне сносно. У моих клиентов на FB1.5 и на более хилых конфигурациях БД побольше (по всем перечисленным тобой "прелестям") работает. И клиентов не мало. FB вообще очень скромные требования имеет к железу, только процессор хорошо кушает, полностью :)


 
Sergey_Masloff   (2005-11-03 12:31) [8]

Присовокуплюсь ;-)))
к
>sniknik ©   (03.11.05 01:38) [1] , Desdechado ©   (03.11.05 11:49) [7]
База около 3 Гб таблиц не знаю около сотни но одна из них общий древовидный справочник. В справочнике миллиона 4 записей в оперативных таблицах больше. Сколько человек работает не знаю ну где-то до 10 и еще процесс-робот который постоянно с довольно большой скоростью лудит данные в базу. На тормоза не жалуются железяка обычный целерон 2.1 256 памяти и кроме того на нем еще как правило в ремот администраторе кто-то сидит.
 Так что непонятно что там не тянет может попересчитать статистику да планы запросов посмотреть? Ну непохоже это на железные проблемы.


 
Sergey13 ©   (2005-11-03 12:46) [9]

2[2] step[B.M.]   (03.11.05 02:10)
>И плюс в запросах надо по 15-20 тис виводить, да не просто select * from
а залезать в процедуры до третьего колена.

Вот и причины плохой производительности, ИМХО.


 
Step[B.M.]   (2005-11-04 21:02) [10]

to Desdechado
> Ты лучше скажи, чем тебя существующая кофигурация не устраивает?
А кто сказазал что мена оно не устраивает? Я просто хотел узнать о возможных нюансах при выборе железа. и все.

to Sergey13
> Вот и причины плохой производительности, ИМХО.
А производительность как хорошая, ибо на планирование бази, в т.ч. оптимизации выделил немало времени. Хотя, не спорю, можно бы и получше сделать.

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

Всем спасибо.


 
Desdechado ©   (2005-11-04 21:22) [11]

> А кто сказазал что мена оно не устраивает?
Обычно покупают новое железо, если старое не устраивает (не работает как надо или умерло вовсе). Можно, конечно, плановые замены оборудования делать, но тогда явно не устраивает прошедший срок службы.
А принуждать начальство тратить деньги вникуда как-то странно, имхо.


 
sniknik ©   (2005-11-04 23:14) [12]

> Это и так вершина его понимания нужности принципиально другого железа.
я тоже так понял. что неустраивает...
ну, а если "проблема" только в том что есть 1500$ и их надо "освоить"... ну это совсем другое дело! даже могу помочь распределить. предлагаю на 500$ купить копм (уже раз в 10 превзойдет описанные нужды) а остальное пустить "братухам" на пиво... за консалтинговые услуги. ;)


 
Fay ©   (2005-11-05 04:28) [13]

2 step[B.M.]   (03.11.05 0:49)
>> Сейчас оно крутится на WIN32
Нет такой ОС. Уточни. Признаться, мне не понятно желание перескочить на другую с Windows, особенно на FreeBSD.

2 sniknik ©   (03.11.05 1:38) [1]
>> любой комп современный ~ за 300$, и sql сервер MSDE),
>> хватит "с головой". даже не стоит выделеть его в
>> отдельный сервер,

1) Поддерживаю идею смены СУБД. Не верю я (спокойно, это личное убеждение) в способности FB.
Правда, автор не пишет (я не разглядел) про среднее/пиковое количество юзеров, т.о. предложитьт конкретную СУБД сложно.

2) Комп за $300 уже есть 8) На самом деле, уже отбитые деньги надо освоить - при правильной (честной, конечно) демонстрации шеф оценит разницу. К тому же нормальное железо не никогда повредит.

3) Тётеньку с её пасьянсами послать (очень вежливо, но твёрдо) сразу подальше - нам ни к чему лишний физ. доступ к серверу.


 
Sergey Masloff   (2005-11-05 10:48) [14]

Fay ©   (05.11.05 04:28) [13]
>спокойно, это личное
Мы уже привыкли ;-)))


 
Fay ©   (2005-11-05 11:04) [15]

2 Sergey Masloff   (05.11.05 10:48) [14]
IB - моя первая любовь. Просто знакомство с MSSQL, ASE и Oracle сильно остудили моё чувство.
8)


 
Sergey Masloff   (2005-11-05 11:29) [16]

Fay ©   (05.11.05 11:04) [15]
>IB - моя первая любовь. Просто знакомство с MSSQL, ASE и Oracle сильно >остудили моё чувство.
Ну я практически аналогично. Последние лет 5 тоже с Oracle в основном. Кстати ASE меня что-то совсем не впечетлил. Про MS SQL плохого ничего не скажу просто слишком он на оракл не похож тяжело с ними параллельно работать поэтому... для небольших задач все же IB ;-))))


 
DSKalugin ©   (2005-11-05 17:30) [17]

Лучшая платформа для ФБ - это Линукс! Фрибздишные порты отстают даже от винды. Брось ерундой болтать, займись лучше нормализацией данных и  оптимизацией запросов. Процессор должен быть не кастрированным. однозначно. Если Интел, то - Пентиум, а не целкерон; если АМД то - атлон или АМД64, но никак не дюрон или семпрон. Это удел студентов и бухгалтеров


 
Desdechado ©   (2005-11-05 19:52) [18]

<off>
> IB - моя первая любовь. Просто знакомство с Oracle остудили моё чувство.
Мое знакомство с Оракл как-то совсем даже в обратную сторону чувство вращает. Не смотря на его огромные возможности, они все какие-то недоделанные, что ли. Что ни возьмешь, везде нужно через задницу делать, иначе не работает. С FB все наоборот - умеет немного, но зато до конца. Причем некоторые вещи умеет такие, которые Оракл только принюхивается или делает робкие шаги в реализации.
Имхо, естественно.
</off>


 
Fay ©   (2005-11-05 20:17) [19]

2 Desdechado ©   (05.11.05 19:52) [18]
>> вещи умеет такие, которые Оракл только принюхивается
Это какие?!


 
YuRock ©   (2005-11-06 05:04) [20]

>>> вещи умеет такие, которые Оракл только принюхивается
> Это какие?!

Быстро устанавливаться, настраиваться, запускаться и останавливаться!

Шутка. А если серьезно - FB - во многих вещах обганяет Оракл в удобстве. Взять, хотябы, "SELECT из процедуры" - в Оракле для этого еще 2 (бесполезных) типа надо в базу запихнуть, да и потом в запросах кастить постоянно - некрасиво... (я про 8-ку - с другими не работал).

Да и документированных багов (не подлежащих исправлению) в О хватает - в ФБ стараются такого не допускать...

Да и вообще, ФБ (ИБ) - очень аккуратный сервер. Чего не скажешь об Оракле. И по надежности - тоже (опять же - я про 8-ку).

Ну блин, разве для маленькой базы (где и дбф хватило бы, если на надежность плевать), надо каждому клиенту Оракл ставить? Смешно :) А вот FB такие клиенты у себя на компе даже и не заметят :)

P.S. Все - мое личное мнение ( основанное на, возможно, ошибочных или редко встречающихся результатах наблюдений :) ), естественно.


 
Desdechado ©   (2005-11-06 19:11) [21]

> Это какие?!
Исключительно на основании собственного опыта работы с ORA9.2, могу ошибаться. Но навскидку:
1. В IB ранних версий уже можно было объявить несколько триггеров на одно событие таблицы, указав последовательность их срабатывания. В Оракл тоже можно объявить такие триггеры, но последовательность их срабатывания не  определена. Поэтому взаимосвязанные операции из разных триггеров приходится пихать в один, чтоб гарантировать последовательность. А в случае необходимости отключить только один из FB-триггеров, в Оракле приходится его модифицировать, а потом возвращать назад. Изврат!
2. В IB при объявлении FOREIGN KEY можно указать ON DELETE [NO ACTION|CASCADE|SET NULL|SET DEFAULT]. В Оракл SET DEFAULT нет, что очень раздражает, т.к. приходится такую незамысловатую логику реализовывать триггером.
3. В IB при объявлении процедуры с параметрами, для них указываешь точный тип и размер. В Оракле этого сделать нельзя. Мне нужно NUMBER(10) или VARCHAR2(30), а приходится безразмерный городить. Почему - не ясно. Видимо, боятся вылетов при некорректных вызовах. А приводит это к трудноуловимым ошибкам. Например, CHAR-параметр всегда имеет длину 2000. Зачем? Могли бы хоть опционально дать возможность размер указывать.
4. Снова о типах. В Оракле при использовании SELECT ... UNION SELECT ... слетают полностью все типы полей. Даже если они один-в-один равны в обеих выборках. Оракл их тупо приводит NUMBER(xxx) к общему NUMBER и т.п. Я понимаю, если бы он равнял по первой выборке или расширял по максимальной среди выборок, но нагло расширять без повода - не понимаю. IB в этом плане гораздо корректнее.
5. И снова о типах. Тут уже упоминались 2 дубовых типа, нужных для выборки из функции. Так вот, вне зависимости от определения типа поля NUMBER(10), объявленого в строчном типе для функции, Оракл все равно его преобразует к безликому NUMBER. Ну, и нафига я тогда определял ему эти типы?
6. В IB простой SQL-командой можно поменять положение колонки в таблице. Как это сделать в Оракле, я так и не нашел. Приходится городить добавление-переносданных-удаление. Понятно, что это редко нужно, но ведь и сделать нетрудно, не так ли?


 
Step[B.M.]   (2005-11-06 20:12) [22]

to sniknik
> Это и так вершина его понимания нужности принципиально другого железа


> любой комп современный ~ за 300$, и sql сервер (MSDE), хватит
> "с головой". даже не стоит выделеть его в отдельный сервер,
>  можно секретаршу посадить пусть в пасьянс играет/документы
> распечатывает. главное ей прав админских не давать и заставлять
> пораньше приходить (чтобы самым первым этот комп включался)


это вершина твоего понимания.. Только без обидняков ;-)

To Fay. тоесть в виду WIN2000, но ОС менять надо и єто будет FreeBSD, ибо одну у меня уже крутится, а зоопарк операчионников у себя разводить не собираюсь. (сугубо личное).

To Desdechado

> А принуждать начальство тратить деньги вникуда как-то странно,
>  имхо

Я здеть только потому чтобы не тратить лишние деньги.

Уже пошло FB vs IB vs Oracle
А ведь вопрос то был о "железе".


 
Step[B.M.]   (2005-11-06 20:15) [23]

К стати, за неделю прирост в одной из таблиц 200 000
мне это начинает нравиться :-)


 
sniknik ©   (2005-11-06 20:40) [24]

> это вершина твоего понимания.. Только без обидняков ;-)
под ту задачу, что была описана описана? адназначна!

разные поздние уточнения не принимаются.


 
Step[B.M.]   (2005-11-06 20:43) [25]

хараша!

В любом случае спасибо, sniknik. :-)



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2005.12.25;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.53 MB
Время: 0.013 c
14-1132856159
Иксик
2005-11-24 21:15
2005.12.25
Как вы относитесь к инициативе Российского правительства по


5-1117695880
Никита
2005-06-02 11:04
2005.12.25
Как заставить TCustomControl не "моргать" при перерисовывание


2-1133945654
Daria
2005-12-07 11:54
2005.12.25
как очистить таблицу???


2-1134047269
_max_
2005-12-08 16:07
2005.12.25
Как проверить, все ли объекты уничтожаются программой?


14-1133797267
Antek
2005-12-05 18:41
2005.12.25
Удаление ярлыков с рабочего стола и пуска в Bat файлах





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский