Проект Сколково

[adb]

Dmitry67 просто в базах данных не особо разбирается.

[Dmitry67]

То есть по словам разработчиков MySQL, 5 милиардов записей размазанные на 200 тыс таблиц - это о чём они слыхали, но сами не пользовали. И они не считают зазорным эти цифры упоминать в основном документе. На MySQL много систем сидит, и слов про то, что она игрушечная, как-то не особо слышно.

Базы данных американуских страховых компаний, с которыми я работал, как правли превыщают 1B записей (только за один год, за всю историю там куда больше)

Впрочем, давайте более приземленный пример. Берем российский супермаркет 24x7. В год он работает 31 миллион секунд. Самой быстрорастущей таблицей является PurchaseItems (неважно как она называется). Грубо говоря каждое пииип! сканера кассы записывает туда одну запись. Касс 30, если в среднем работает 5, по одному товару в секунду (реально сканирубт быстрее но с перерывами) получим 150M записей в год. Это от одного уивермага. Сеть наработает миллиард куда быстрее.

Так что не стоит думать что миллиард - это много.

[uncle_Pasha]

Сеть наработает миллиард куда быстрее.

Нужны ли все эти записи online?

Удачи!

[Dmitry67]

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

[adb]

Так что не стоит думать что миллиард - это много.

А как насчет запихать MS SQL на наладонник под WinCE или в какой-нибудь небольшой ящик под vxWorks, Qnx, BSD или к примеру в камни, которые использовали английские шпионы не так давно? И сколько это будет стоить?
Какой смысл сравнивать танкер с моторной лодкой? У них совершенно разные предназначения и ниши использования. Для большинства ниш миллиард записей слишком много и используют бесплатную postgreSQL или приведенный аналог.

[Dmitry67]

MS SQL для наладонника?
http://www.microsoft.com/downloads/deta ... laylang=en
Microsoft SQL Server Compact 3.5 for Windows Mobile

А вообще зачем наладонник?
Вы карточку 32Gb видели? Какой у нее размер?

[uncle_Pasha]

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

Чаще всего, для построения такого рода отчетов нужна аггрегированная информация.
Понятно, что если база позволяет, то можно все держать в одной куче. Вопрос состоит только в эффективности такого рода подхода. Если в системе реализована скажем процедура периодической "архивации" (очистки оперативных таблиц) то такая система при прочих равных будет более производительной при меньших ресурсах, и фактически без ущерба функциональности.
А объединить несколько таблиц для построения отчета раз в квартал - это умеет практически любая СУБД.

Удачи!

[Capricorn]

На мой взгляд критерии невнятные,

По-моему, критерии вполне ясные - это будет элитный город, живущий по своим правилам, со своей милицией. Рублевка, Николина Гора и т.д - это лишь островки среди "народа". Олигархам не очень удобно, все равно "натыкаешся" на черт знает кого. А здесь целый город, специально для "своих". Цены на всё бешеные, просто так, без "разрешения" не поселишься. Напустят немного ученых, ну они публика приятная, вежливая. понастроят оффисов для западных компаний - ляпота .. Каждый год по новому Гуглу - цели определены, задача ясна, за работу товарищи

Сопредседатель Фонда "Сколково" Виктор Вексельберг выступил на слушаниях в Госдуме, где рассказал, что именно будет представлять собою российский "инноград". В частности, он назвал пять элементов, которые соединит в себе Сколково: это академическая наука, филиалы ведущих институтов; образовательный исследовательский центр; представительства крупных компаний, которые будут связывать бизнес и науку; инкубатор, связанный с поддержкой "стартапов", и наконец - инфраструктурная среда, город, удобный для жизни и отдыха.
Все вместе это должно обеспечить "непрерывный процесс генерации и реализации инновационных идей, создания и продажи интеллектуального продукта", считает Вексельберг. "Каждый год даешь по одному Google - это лозунг приблизительно выражающий, то чего бы нам хотелось сделать в итоге, - объяснил он цели проекта "Сколково".

[uncle_Pasha]

А здесь целый город, специально для "своих". Цены на всё бешеные, просто так, без "разрешения" не поселишься. Напустят немного ученых, ну они публика приятная, вежливая. понастроят оффисов для западных компаний - ляпота .. Каждый год по новому Гуглу - цели определены, задача ясна, за работу товарищи

Надо бы еще колючкой огородить. Чтоб не разбежались.

Удачи!

[Sergunka]

На мой взгляд критерии невнятные,

По-моему, критерии вполне ясные - это будет элитный город, живущий по своим правилам, со своей милицией. Рублевка, Николина Гора и т.д - это лишь островки среди "народа". Олигархам не очень удобно, все равно "натыкаешся" на черт знает кого. А здесь целый город, специально для "своих". Цены на всё бешеные, просто так, без "разрешения" не поселишься. Напустят немного ученых, ну они публика приятная, вежливая. понастроят оффисов для западных компаний - ляпота .. Каждый год по новому Гуглу - цели определены, задача ясна, за работу товарищи

Сопредседатель Фонда "Сколково" Виктор Вексельберг выступил на слушаниях в Госдуме, где рассказал, что именно будет представлять собою российский "инноград". В частности, он назвал пять элементов, которые соединит в себе Сколково: это академическая наука, филиалы ведущих институтов; образовательный исследовательский центр; представительства крупных компаний, которые будут связывать бизнес и науку; инкубатор, связанный с поддержкой "стартапов", и наконец - инфраструктурная среда, город, удобный для жизни и отдыха.
Все вместе это должно обеспечить "непрерывный процесс генерации и реализации инновационных идей, создания и продажи интеллектуального продукта", считает Вексельберг. "Каждый год даешь по одному Google - это лозунг приблизительно выражающий, то чего бы нам хотелось сделать в итоге, - объяснил он цели проекта "Сколково".

Да, что и сказать нелегко там "живут среди монстров"

[Dmitry67]

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

Чаще всего, для построения такого рода отчетов нужна аггрегированная информация.
Понятно, что если база позволяет, то можно все держать в одной куче. Вопрос состоит только в эффективности такого рода подхода. Если в системе реализована скажем процедура периодической "архивации" (очистки оперативных таблиц) то такая система при прочих равных будет более производительной при меньших ресурсах, и фактически без ущерба функциональности.
А объединить несколько таблиц для построения отчета раз в квартал - это умеет практически любая СУБД.

Удачи!

Вы рассказываете в упрощенном виде механизм PARTITIONING.
Он делается в MS SQL либо через Partitioned views, тогда разные партиции хранятся в разных таблицах, а view имитирует что таблица одна
Либо через более современный механизм Partitioned tables.

Российская база не поддерживает ни того ни другого раз;
Во вторых PARTITIONING не исключает необходимости найти чтото по ID неизветсно в какой партиции
так что поддердивать индексы по миллиардам все равно надо

[Capricorn]

А здесь целый город, специально для "своих". Цены на всё бешеные, просто так, без "разрешения" не поселишься. Напустят немного ученых, ну они публика приятная, вежливая. понастроят оффисов для западных компаний - ляпота .. Каждый год по новому Гуглу - цели определены, задача ясна, за работу товарищи

Надо бы еще колючкой огородить. Чтоб не разбежались.

Удачи!

Наоборот, что бы не набежали

[uncle_Pasha]

А здесь целый город, специально для "своих". Цены на всё бешеные, просто так, без "разрешения" не поселишься. Напустят немного ученых, ну они публика приятная, вежливая. понастроят оффисов для западных компаний - ляпота .. Каждый год по новому Гуглу - цели определены, задача ясна, за работу товарищи

Надо бы еще колючкой огородить. Чтоб не разбежались.

Наоборот, что бы не набежали

Хорошо, колючкой в два ряда и КСП между ними.

Удачи!

[Очень Лысый]

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

Чаще всего, для построения такого рода отчетов нужна аггрегированная информация.
Понятно, что если база позволяет, то можно все держать в одной куче. Вопрос состоит только в эффективности такого рода подхода. Если в системе реализована скажем процедура периодической "архивации" (очистки оперативных таблиц) то такая система при прочих равных будет более производительной при меньших ресурсах, и фактически без ущерба функциональности.
А объединить несколько таблиц для построения отчета раз в квартал - это умеет практически любая СУБД.

Удачи!

Вы рассказываете в упрощенном виде механизм PARTITIONING.
Он делается в MS SQL либо через Partitioned views, тогда разные партиции хранятся в разных таблицах, а view имитирует что таблица одна
Либо через более современный механизм Partitioned tables.

Российская база не поддерживает ни того ни другого раз;
Во вторых PARTITIONING не исключает необходимости найти чтото по ID неизветсно в какой партиции
так что поддердивать индексы по миллиардам все равно надо

Не думаю, что Linter позиционируется как СУБД для аналитики, тем более на очень больших обьемах данных. Скорее это легкая база для OLTP приложений. Пойнт не в этом. Товарищ выше просил привести пример российских инноваций. Вот один из них и который как не странно делается не в Маскве.

ИМХО - Мозги у наших ученных, инженеров, программистов есть, чай не тупее индусов. В России есть ну или была до недавнего времени хорошая школа преподавания естественных наук и инженерных дисциплин. Мешает херовый менеджмент, родное гос-во + русский национальный менталитет. Хочется надеется, что что-то изменится с приходом Сколково, даже если его КПД будет ну 5%-10%.

[helg]

База данных - как газ - способна легко занять весь доступный объём. Только не надо ей это давать делать. Есть баллоны, газгольдеры и прочая артибутика - для того, чтобы этого не допустить.

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

Были бы прописаны чёткие ограничения по размерам, когда оно всё только начиналось, всё было бы запроектировано на нужном уровне заранее, и бомбы бы не тикало. Впрочем, палка о двух концах: когда у заказчика тикает, он легче раскошеливается.

Когда максимальный размер таблицы известен заранее, как размер int'а, дизайн базы получается гораздо удачнее. А маркетинговый подход производителей, "вы можете не заботиться о размере таблиц и базы - пишите сколько хотите" - это путь в болото, в которое чем дальше получится зайти, тем дороже выкарабкиваться.