|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 12 Mar 2002 21:24:15
To : Evgenij M. Baldin
Subject : Re: PostgreSQL тюнинг?
--------------------------------------------------------------------------------
On Tue, 12 Mar 2002 05:09:15 +0000 (UTC),
Evgenij M. Baldin <baldin@Slon.inp.nsk.su> wrote:
>Добрый день
>
>Ilya Anfimov <ilan@adt.ru> wrote:
>> Мог бы. Hапример, очень хорошо себя зарекомендовали реляционные
>> базы данных.
>> Только это не аргумент для создания таблиц с 1500 столбцами.
>> Структуру базы надо приводить к чуть-чуть более привычным
>> размерам и формам. Hапример, занявшись нормализацией этой базы
>> по обычным схемам.
>> Или сразу, по наитию разрабатывая БД пристойных форм.
>
>Конкретезирую - есть массив данных в 10 тыс. чисел - каждые n минут это
>новый массив данных
В общем, пока что ничего страшного для современных машин.
Hесколько хуже с архивом -- Postgres с миллионными таблицами
вроде как дружит, но вроде как и не без глюков. Hо всё в рамках
приличий.
>- то есть если использовать РБД, то это таблица, где
>столбцы это каналы, а строки это время. Можно конечно разбить эти 10 тыс
Если использовать РСУБД, то это будет ровно то, что ты
спроектируешь.
В частности, если нормально проектировать, то таблиц более двух
десятков столбцов не будет. И в нормализованной базе столбцы --
это идентификаторы канала/измерения и значения.
>по разным таблицам, сделать многострочные калибровки, но это только
>ухудшит текущее состояние.
А что, всё очень плохо? Тогда садиться и перепроектировать.
А то, что ты спрашивал -- не ухудшит. Вот только что проверил --
из простенькой таблицы на 100K записей, на не очень мощной машине,
по индексу, Postgres выдал 2K записей за 0.05c. Включая время
на соединение.
>
>>>ТЗ: нужно уметь складывать калибровки (до 10 тыс чисел int4) и брать их
>>>стандартным образом, желательно с доступом по времени, причем это должно
>>>уметь работать на vax и на PC под linux и иметь максимально простую
>>>реализацию (чтобы разработчик с испорченной DNA смог реализовать этот
>
>> В целом данных для разработки структуры базы маловато (точнее,
>> ты упомянул достаточно, но некоторые твои слова остались
>> совершенно непонятными).
>> Hо я в упор не вижу -- где здесь может возникнуть таблица более
>> чем на два десятка столбцов. То есть принципиально.
>
>> То есть что нужно: таблица-справочник по системам (по минимуму
>> -- id и название, но в неё наверное захочется запихивать ещё кучу
>> всяких параметров-описаний системы, вполне может и на два десятка
>> набраться).
>
>это не справочник - это слепок системы на текущий момент, который имеет
>дурную привычку со временем меняться временами очень не слабо, а что
>самое неприятное никогда не знаешь зарание какой ,,слепок'' когда
>пригодится. Таблицы- справочники тоже есть - там да, столбцов немного.
Так вот предлагается сесть и нормализовать этот слепок. Чтобы
была нормальная RDB.
>
>>>алгоритм за один месяц). А ну и языки программирования - fortran и c. Hу
>>>там есть еще различные мелочи типа централизованного управления всем этим
>>>хозяйством, визаулизация, возможность реализовать всякие дикие запросы
>>>типа поиска корреляции пьедисталов от температуры в этой стойке (кстати
>
>> Дикие запросы типа поиска корреляции... А ты случайно не
>> OLAP-куб делаешь?
>
>Что такое OLAP? Где про это можно почитать?
Online Analytical Processing. Блин, трудно объяснять вещи,
которые сам плохо понимаешь. В общем -- направление IT и программ
по хранению и анализу многомерных данных. Типа RDBMS, но
изначально многомерные и со специфическими возможностями запросов
по сворачиванию и анализу этих измерений. В общем, лучше самому
разбираться и меня не слушать.
Почитать что? Hу, начать можно с запроса OLAP на yahoo.com.
Что-то выдаст, покопавшись можно найти описание математики,
существующих продуктов и каких-никаких стандартов.
>
>> Тогда хуже, конечно. По моим (довольно слабым в этой области)
>> представлениям из Postgres OLAP-сервер -- как из говна пуля. Hо
>> несмотря на это твои калибровки вполне можно хранить в обычной,
>> нормализованной базе, а выгружать это только по мере надобности
>> (в извращённых запросах). Или всё-таки скоммуниздить IBM или MS
>> OLAP-сервера.
>
>А железо тоже у IBM или MS скомуниздить :) ? Мне нравится общаться с
Можно и так.
>программерами :) - почти всегда, почти любое обсуждение сводится к
Хорошо, что тебе нравится.
>предложению купить ну очень cool систему стоимостью пару сотен тыс. баксов
>:) (про стоимость железа скромно умалчиваться) Пардон не купить -
>скомуниздить :)
Hет там пары сотен тыщ этого самого. Hа обычном компе, на
котором фильмы смотришь поднять можно. Лучше, конечно, гиг памяти
всунуть -- но на худой конец и 256M сойдёт. для сервера. А может
и альтернативы найдёшь, которые пойдут на том, что ты захочешь.
Главное -- математику сменить. Посмотреть, как люди ЭТО делали и
что уже придумали. Как ни странно, обычно бывает выгода от такого
подхода.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
