powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большая БД
25 сообщений из 25, страница 1 из 1
Большая БД
    #37400539
Red Wind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день,
Передо мной в ближайшей перспективе встанет разработка системы в которой будет использоваться БД с большим объёмом данных. Точного ТЗ ещё нет, но ориентировочно каждую секунду будет происходить 4000 инсертов. Точной структуры данных пока тоже нет, но одна запись будет содержать не менее 50 байт. 4000 в секунду это примерно 12*10^10 инсертов в год, помноженные на 50 байт дают 5 Тб в год. Сохранённые данные должны храниться вечно. Сохранённые данные будут анализироваться различными алгоритмами, которые предоставляются нашими клиентами. Особенность алгоритмов в том, что они будут последовательно (это важно) анализировать данные за определённый период времени (месяцы, годы).
До этого я никогда не сталкивался с такими объёмами данных. Работал с MS SQL базами до 5 Гб. Теперь даже не знаю как подойти к такой задаче.
Вопросы:
1) Подскажите, в какую сторону стоит углубить свои знания, что бы подготовиться к старту проекта?
2) Какую бд стоит выбрать?
3) Гугл говорит что есть такое понятие как аналитическая бд, но я не могу найти примеры таких бд, и точную сферу их применения. Я на правильном пути? Что можете сказать про аналитические БД?
4) Так же есть вариант не использовать БД, а писать данные прямо в файловую систему. Но мне кажеться это слишком маргинальным. Когда будет оправдан такой подход?
...
Рейтинг: 0 / 0
Большая БД
    #37400587
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот и подумайте, как и где вы будете все это дело хранить, бекапить, восстанавливать при необходимости. На счет аналитических - это тоже СУБД построенная по принципу DWH. Возможно вам понадобится даже 2 БД, т.к. трудно представить как уживутся OLTP и DWH на таких объемах вместе.Red Wind5 Тб в год. Сохранённые данные должны храниться вечно.
...
Рейтинг: 0 / 0
Большая БД
    #37400702
Volochkova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Больше вопрос, где Вы возьмете железо по 5 ТБ в год/
И какая аналитика Вам нужна.
Это корзинка с 24 hdd в рейде 10 и 4 запаски.
И такие корзинки надо пачковать каждый год.

А по технологии все просто.
Ставите текущую базу в которую и кидают данные. Это буфер.
Раз в час из него данные сливаете в боевую базу где и идете аналитика (это если текущие операции не критичны)
Если критичны - то написать запросы, которые таскают данные не только по статистике, то цепляют буфер.
Тригерами на инсерт, можно делать апдейт статистических уже сгруппированных данных.


В MS SQL можно ставить галку сжимать данные, тогда партиция занимать будет меньше места. Выгода 1 к 7. Но считывание понятно будет дольше.
...
Рейтинг: 0 / 0
Большая БД
    #37400926
Фотография samatom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red Wind,

мало входной информации.
Речь идет о серьезном проекте, высоконагруженной системе. Здесь нужны опытные специалисты. Трудно себе представить, что такую систему будет проектировать человек с опытом работы с базой 5 Гб (не в обиду будет сказано). Об этом целые книги пишут =). А Вы хотите парой вопросов определиться с решением. Судя по объему транзакций и базы - речь идет не о мелкой конторе. Возможно ретейлер или игорное заведение. Как уже было сказано - необходимо 2 базы (в идеале их должно быть не менее 6 - для тестов, разработки, ПСИ). Определить технологические окна - для бэкапа и загрузки данных в DWH (а то было сказано 4000 инсертов - неужели 24 часа в сутки - если это так, то нужно думать об инкрементальных обновлениях, хотя всё уже давно придумано). Опять же 4000 инсертов от одной сессии или же от 4000 подключений? Нужно всё детально проработать - начиная от аппаратной архитектуры до архитектуры подсистемы резервного копирования. Главное - определиться с бюджетом. Выбрать политику лицензирования, отбирать надежных поставщиков и т.д. Нужен ли здесь BI или Data Mining и какая СУБД - по маленькому посту не скажешь. Файловая система - в топку. Есть вариант посмотреть в сторону облаков (если стеснены в деньгах), хотя сам ни разу с ними не работал. Если денег валом - Exadata, Netezza, Teradata. Имхо, проект минимум на полгода и на команду не менее 5 человек. Цена ошибки очень велика в таких дорогостоящих проектах, особенно, если учесть статистику - если проект и завершается - то ни один не укладывается ни в срок, ни в бюджет.
...
Рейтинг: 0 / 0
Большая БД
    #37400938
Фотография samatom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red Wind,

ну а если нет времени на всё, то посмотрите в сторону Oracle mat view (with инкрементальный fast refresh). Опять же, если бюджет позволит Oracle c этой опцией в купе с выбранным железом.
...
Рейтинг: 0 / 0
Большая БД
    #37400950
Фотография samatom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red WindДобрый день,
Особенность алгоритмов в том, что они будут последовательно (это важно) анализировать данные за определённый период времени (месяцы, годы).
Что значит последовательно? FULL SCAN? Опять же одной таблицы или большого числа соединений таблиц? Агрегаты или детальные данные? Тогда точно Exadata, Netezza, Teradata - MMP-архитектура, массивно-параллельные СУБД, остальные системы этого уровня в РФ не распространены/не поддерживаются.
Посмотрите вот этот полезный ресурс - www.infology.ru
...
Рейтинг: 0 / 0
Большая БД
    #37400999
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 18.08.2011 0:18, Red Wind wrote:

> 4) Так же есть вариант не использовать БД, а писать данные прямо в файловую
> систему. Но мне кажеться это слишком маргинальным. Когда будет оправдан такой
> подход?

Это как раз то, о чём надо подумать в первую очередь.
Данные в БД просто так не нужны, данные в БД нужны, если
они там смогут быть обработаны. Если ты будешь обрабатывать
данные только вне БД, (это будет делать не СУБД), то смысла
пихать их туда (в БД) нет никакого.

В общем, анализируйте в перую очередь то, как и какими средствами
ваши данные надо будет обрабатывать.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большая БД
    #37401254
Red Wind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Volochkova , примерно так я себе и представляю всё. Первые наброски архитектуры системы уже есть. Когда всё осмыслю, выложу свои прикидки сюда.

samatomТрудно себе представить, что такую систему будет проектировать человек с опытом работы с базой 5 Гб (не в обиду будет сказано). Об этом целые книги пишут =).
Можно сказать что это карьерный рост. По поводу книг, что можете порекомендовать?

samatomОпять же 4000 инсертов от одной сессии или же от 4000 подключений?
Будет около 20 источников данных, но я думаю будет один или два наших сервиса агрегатора которые уже будут производить запись в буферную бд.

samatomЕсли денег валом - Exadata, Netezza, Teradata. Имхо, проект минимум на полгода и на команду не менее 5 человек.
Посмотрел цены на эти продукты. Серьёзно так. Очень не уверен что у нас будет такой бюджет. Сейчас я начинаю исследования связанные с проектом, потом ко мне подключиться ещё 2 разработчика. Первая версия должна выйти примерно через год после начала девелопмента.

samatomЧто значит последовательно? FULL SCAN? Опять же одной таблицы или большого числа соединений таблиц? Агрегаты или детальные данные? Тогда точно Exadata, Netezza, Teradata - MMP-архитектура, массивно-параллельные СУБД, остальные системы этого уровня в РФ не распространены/не поддерживаются.
Посмотрите вот этот полезный ресурс - www.infology.ru
Наш проект по сути, является сервисом на котором третьесторонние компании смогут тестировать свои алгоритмы по анализу финансовых данных на общирной статистике из разных источников данных. Клиент предоставляет нам свой кусок кода на c#, мы его выполняем на своих серварах последовательно подтягивая данные из БД.
infology.ru выглядит не плохо, надо будет полистать.

MasterZivЭто как раз то, о чём надо подумать в первую очередь.
Данные в БД просто так не нужны, данные в БД нужны, если
они там смогут быть обработаны. Если ты будешь обрабатывать
данные только вне БД, (это будет делать не СУБД), то смысла
пихать их туда (в БД) нет никакого.

В общем, анализируйте в перую очередь то, как и какими средствами
ваши данные надо будет обрабатывать.
Сейчас я бы назвал это основным вопросом. Использовать ли нам БД. С одной стороны отказ от БД несёт в себе кучу потенциальных проблем. Но с другой дешевле и даёт большую гибкость. С MasterZiv не согласен, всётаки БД это именно хранение, а не обработка.

Резюмируя, вопросы остаются всё теже. Особенно интересует 4 вопрос. Так же, сегодня выложу свои прикидки архитектуры.
...
Рейтинг: 0 / 0
Большая БД
    #37401340
Фотография samatom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red Wind,

По поводу роста - только приветствую, честно. Но я как бы намекал, что если сомневаетесь, то лучше обратиться к интеграторам - они Вам помогут с первым проектом, Вы за это время опыта наберетесь и дальнейшие проекты будете весьти сами.
По поводу литературы - как раз тема есть - http://www.sql.ru/forum/actualthread.aspx?tid=872220
Также на том же infology.ru есть список книг must read по тематике DWH. Жаль проект перестал развиваться. Но есть много и других блогов и ресурсов.
Как вариант - почитать об успешных проектах на сайтах интеграторах, найти презентации.

По поводу "БД это именно хранение, а не обработка" - типичное мнение разработчика, а не "базиста" =)
БД - это хранение с целью обработки. Обработка данных должна вестись вся на стороне СУБД, а не тянуться по каналам на сторону клиента для обработки.
...
Рейтинг: 0 / 0
Большая БД
    #37401383
Red Wind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
samatomПо поводу роста - только приветствую, честно. Но я как бы намекал, что если сомневаетесь, то лучше обратиться к интеграторам - они Вам помогут с первым проектом, Вы за это время опыта наберетесь и дальнейшие проекты будете весьти сами.
По поводу литературы - как раз тема есть - http://www.sql.ru/forum/actualthread.aspx?tid=872220
Также на том же infology.ru есть список книг must read по тематике DWH. Жаль проект перестал развиваться. Но есть много и других блогов и ресурсов.
Как вариант - почитать об успешных проектах на сайтах интеграторах, найти презентации.

По поводу "БД это именно хранение, а не обработка" - типичное мнение разработчика, а не "базиста" =)
БД - это хранение с целью обработки. Обработка данных должна вестись вся на стороне СУБД, а не тянуться по каналам на сторону клиента для обработки.
Какие блоги, сайты интеграторов и тп вы можете порекомендовать?
Так что тогда понимается под обработкой? Из ваших слов про обработку и хранение выходит, что вы тоже предлашаете не использовать БД. Я правильно понял?
...
Рейтинг: 0 / 0
Большая БД
    #37401392
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 18.08.2011 13:21, Red Wind wrote:

> и даёт большую гибкость. С MasterZiv не согласен, всётаки БД это именно
> хранение, а не обработка.

Если ты только храниш данные в БД, то БД тебе нахрен не нужна.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большая БД
    #37401524
Red Wind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivOn 18.08.2011 13:21, Red Wind wrote:

> и даёт большую гибкость. С MasterZiv не согласен, всётаки БД это именно
> хранение, а не обработка.

Если ты только храниш данные в БД, то БД тебе нахрен не нужна.

Почему?
...
Рейтинг: 0 / 0
Большая БД
    #37401581
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VolochkovaВ MS SQL можно ставить галку сжимать данные, тогда партиция занимать будет меньше места. Выгода 1 к 7. Но считывание понятно будет дольше.

Ну, в 7 раз сжать - это слишком оптимистично. Но из моей практики в 4-5 раз вполне возможно.

И чтение все же будет быстрее: чтобы проанализировать 1 год, надо прочитать не 5 Тб, а 1 Тб.
Платой за это будет несколько большая нагрузка на процессор.

Red WindНаш проект по сути, является сервисом на котором третьесторонние компании смогут тестировать свои алгоритмы по анализу финансовых данных на общирной статистике из разных источников данных. Клиент предоставляет нам свой кусок кода на c#, мы его выполняем на своих серварах последовательно подтягивая данные из БД .


Если будет задача типа проанализировать данные за год для чего-либо, то вы просто не дождетесь ее решения с построчным подтягиванием данных.
...
Рейтинг: 0 / 0
Большая БД
    #37401586
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 18.08.2011 14:54, Red Wind wrote:

> Почему?

Потому что с тем же успехом ты бы мог данные просто удалить.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большая БД
    #37401591
Red Wind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
КритикЕсли будет задача типа проанализировать данные за год для чего-либо, то вы просто не дождетесь ее решения с построчным подтягиванием данных.
Не совсем точно выразился. Построчной обработкой. А чтение будет осуществляться блоками.
...
Рейтинг: 0 / 0
Большая БД
    #37401669
Фотография samatom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик,

Exadata сжимает данные от 10 до 50 раз - http://www.youtube.com/watch?v=4qzFFBff34g
...
Рейтинг: 0 / 0
Большая БД
    #37401811
Volochkova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
КритикVolochkovaВ MS SQL можно ставить галку сжимать данные, тогда партиция занимать будет меньше места. Выгода 1 к 7. Но считывание понятно будет дольше.

Ну, в 7 раз сжать - это слишком оптимистично. Но из моей практики в 4-5 раз вполне возможно.


Зависит от структуры базы. Я на 81 1с гоняла.
Почти в 7 раз / реад онли + сжатие/
Но ТС больше надо думать про главное - какие отчеты надо.
А так можно поставить BluRay и на него катать месячные копии пакетов, а в базе уже хранить только результаты для аналитических запросов.
А 1 раз в месяц - админ пришел за зп и диск поставил чистый
...
Рейтинг: 0 / 0
Большая БД
    #37404110
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red Wind1) Подскажите, в какую сторону стоит углубить свои знания, что бы подготовиться к старту проекта?
1. Алгоритмическое
2. Internals выбранной БД
3. High end железо
4. Best practises работы с большими объёмами данных вообще и для этой СУБД

Red Wind2) Какую бд стоит выбрать?
Хм. Это как бы не лёгкий вопрос. Тут как бы надо смотреть на предполагаемую обработку, проектировать решение и прикидывать бюджет, и пытаться всё это в совокупности загнать в реальные возможности.

Если сферически в вакууме то конкурентов Exadata и соответственно Oracle пока вроде не наблюдается. Но тут как бы надо внимательно смотреть на задачу, чтобы не стрелять ни из пушки по воробьям, ни из рогатки по танкам.

Red Wind4) Так же есть вариант не использовать БД, а писать данные прямо в файловую систему. Но мне кажеться это слишком маргинальным. Когда будет оправдан такой подход?
Не в данном случае.
...
Рейтинг: 0 / 0
Большая БД
    #37405429
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Red WindНе совсем точно выразился. Построчной обработкой. А чтение будет осуществляться блоками.
какими еще "блоками"? не припомню никаких блоков в SQL. Тут уже говорили про обработку, вообще из азов проектирование БД делается так
1. определяются входные данные
2. определяется, как входные данные будут храниться
3. определяется, как хранимые данные будут обрабатываться и выводиться
4. если с пунктом 3 есть проблемы, возвращаемся в пункт 2

Далее, при хранении больших объемов данных основной вопрос - именно в их обработке и степени детализации. Редко когда нужно знать, что происходило 5 лет назад в конкретный день или час. Если нужно - то эти данные хранятся. Но если нужно знать общую картину за месяц те же 5 лет назад, то значит, нужно хранить каким-то образом дополнительно агрегированные данные. То есть, количество хранимых данных увеличивается, но при этом бОльшая часть операций над "старыми" данными ускоряется.

Рискну утверждать (не зная вашей прикладной области), что наиболее распространенной является схема
- есть БД для "оперативных данных", сроком хранения например в 1 год
- устаревающие данные постепенно переносятся в архивную БД
- архивная БД может в свою очередь периодически избавляться от "совсем старых данных".

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

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

p.s. я всегда со скепсисом относился к системам с подобной скоростью накопления информации. 4000 записей в секунду - это достаточно большой объем информации, которую человек (а все ведь для человека делается, так?) способен проанализировать много дольше чем за минуту. А в минуту уже будет 240к записей. В час - 14 миллионов. Кто будет анализировать (и зачем) 14 миллионов записей за конкретный час, например трехмесячной давности?

Грубый пример - необходимость хранения бухгалтерской документации за 5 лет. Хранение да, но копаться в накладных за конкретный день будет только налоговая инспекция в случае проверки. Самой компании нужны будут обороты за конкретный день, неделю, месяц и т.п. А пересчитывать каждый раз эти обороты по исходным данным - маразм.
...
Рейтинг: 0 / 0
Большая БД
    #37405461
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> сервисом на котором третьесторонние компании смогут тестировать свои алгоритмы по анализу финансовых данных

Странный характер финансовых данных. 4 тыс. инсертов в секунду - ни с чем не стыкующаяся цифра. 20 источников - тоже странное количество. Для биржевых данных это смешные цифры, для статистических - невозможные. Для таймсерий база данных не нужна, а для статистических данных вы вряд ли сможете ее адекватно спроектировать, СУБД должна вас беспокоить в последнюю очередь.

> на общирной статистике из разных источников данных

Если это открытые источники, клиенту ваш сервис нафиг не нужен, поскольку гораздо более качественный и разносторонний анализ он в состоянии сделать самостоятельно, - куча готовых инструментов. Если закрытые, сильно сомневаюсь, что лицензионные соглашения позволяют их перепродажу. Темните вы, уважаемый.
...
Рейтинг: 0 / 0
Большая БД
    #37408207
AnyaNartova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv В час - 14 миллионов. Кто будет анализировать (и зачем) 14 миллионов записей за конкретный час, например трехмесячной давности?
Ну вы даете :) А чем по-вашему все современные BI системы занимаются? И анализируют, и модели прогнозирования на основании вот этих самых исторических данных строят... много чего.

kdvГрубый пример - необходимость хранения бухгалтерской документации за 5 лет. Хранение да, но копаться в накладных за конкретный день будет только налоговая инспекция в случае проверки. Самой компании нужны будут обороты за конкретный день, неделю, месяц и т.п. А пересчитывать каждый раз эти обороты по исходным данным - маразм.
Не совсем так. Фиксированные агрегаты показывают только один срез (или набор срезов) данных. Если требуется именно свободная аналитика, с непредусмотренными ранее параметрами анализа (непонятно заранее какие группировки нужны, какие агрегаты), да еще к тому же и с необходимостью детализации на любой уровень, - то используется как правило сочетание агрегатов и исходных данных. Так что без хранения исходных данных для получения полного анализа - не обойтись.

guest_20040621Если это открытые источники, клиенту ваш сервис нафиг не нужен, поскольку гораздо более качественный и разносторонний анализ он в состоянии сделать самостоятельно, - куча готовых инструментов. Если закрытые, сильно сомневаюсь, что лицензионные соглашения позволяют их перепродажу.
И тоже не так. Существует такое направление бизнеса - агрегаторы данных. Они как раз и занимаются сбором в единое хранилище всевозможной публичной и частной информации по какой-то заданной теме, а потом продают возможность анализа вот этих собранных данных всевозможным заинтересованным компаниям. Или уже готовые отчеты по запросу. Такая услуга пользуется спросом, потому что выполнить консолидацию данных из совершенно разных источников - не такая уж простая задача. У нас просто этот рынок пока еще не очень развит. Если кто-то собирается этим заняться - это здорово.

To TC
Где-то здесь уже упомяналось, -я согласна: кроме выбора БД, вам стоит подумать еще и про модель данных. Гляньте на что-нибудь готовое для вашей области. Самому разработать что-то такое с нуля - довольно тяжелая задача.

Что касается самой БД - включите в список рассматриваемого Sybase IQ. Это сервер БД разработанный именно для аналитики. И одной из его особенностей является то, что он хорошо жмет данные, - объем базы со всеми индексами получается меньше чем объем исходных данных. При ваших объемах это позволит неплохо сэкономить на железе.
...
Рейтинг: 0 / 0
Большая БД
    #37408594
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> И тоже не так.

Вы даже приблизительно не представляете себе специфику работы рынков. Есть Bloomberg. Данных больше, чем у Bloomberg, нет ни у кого. Терминал стОит пару килобаксов в месяц. Причем, независимо от количества рабочих мест, каждый терминал. Так вот лавка, которая может арендовать такой терминал, тем более в состоянии нанять студента за двести долларов, чтобы мониторить не интересные Bloomberg источники. А если у лавки нет денег на аренду терминала, на рынке им делать нечего. Понимаете, да?

> это здорово

Это очередной лохотрон. Долго объяснять, почему.
...
Рейтинг: 0 / 0
Большая БД
    #37414357
AnyaNartova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621Вы даже приблизительно не представляете себе специфику работы рынков. Есть Bloomberg. Данных больше, чем у Bloomberg, нет ни у кого. Терминал стОит пару килобаксов в месяц. Причем, независимо от количества рабочих мест, каждый терминал. Так вот лавка, которая может арендовать такой терминал, тем более в состоянии нанять студента за двести долларов, чтобы мониторить не интересные Bloomberg источники. А если у лавки нет денег на аренду терминала, на рынке им делать нечего. Понимаете, да?

Я может быть и не представляю себе специфику работы рынков, зато я хорошо представляю себе специфику работы хранилищ данных, содержащих сотни миллионов записей и специфику требований пользователей, предъявляемых к такого рода хранилищам. И именно о них я говорю. Зачем-то же люди их организуют? А? Они все идиоты? :)
Форум OLAP и DWH по-вашему зачем существует? :)

guest_20040621Это очередной лохотрон. Долго объяснять, почему.

Почитайте тут , может проявится какое-то понимание и слегка расширится картина мира :)
...
Рейтинг: 0 / 0
Большая БД
    #37414367
AnyaNartova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621, к слову, упомянуты вами Bloomberg сам по себе является агрегатором данных.
...
Рейтинг: 0 / 0
Большая БД
    #37414391
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я может быть и не представляю себе специфику работы рынков

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

> И именно о них я говорю.

Напрасно. Домашнее задание: выяснить, что такое таймсерии и как их хранят. Опционально: определить особенности продолжающихся статистических отчетов. Можно на примере Росстата.

> Они все идиоты?

Не все. 4% (двойное правило Парето) в выбранной прикладной области - вполне вменяемые люди.

> Почитайте тут,

Удивлен, что не ссылаетесь на надписи на заборе или сарае.

Девушка, иногда лучше жевать, чем говорить. Bloomberg - это не только котировки и статистика, в отношении части которых агентство действительно выступает агрегатором, это ведущая специализированная информационная структура с кучей эксклюзивного контента, до уровня которой, кстати сказать, в обозримом будущем никто не дорастет.
...
Рейтинг: 0 / 0
25 сообщений из 25, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большая БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]