От Sergey Ilyin
К All
Дата 08.09.2004 15:23:17
Рубрики Современность;

С технической стороны -- ненаучная фантастика. Фэнтези, сиречь.

Простите, вы к разработке баз данных какое-нибудь отношение имеете?

>Технические возражения:
>1. Нет таких КПК
>С объемом от 0.1 до 1 Террабайта пока нет. Кто-то тут сомневается что они будут в ближайшем будущем?

>4. Маломощность процессоров для поиска в базе со 150 млн записей

Берем в зубы хороший такой интернет-сайт ТРС (который Transaction Processing Performance Council -- меряет рекорды производительности серверов). http://www.tpc.org/tpch/results/tpch_perf_results.asp

И тыкаем в любой результат в таблице про 1 TB базы данных. Вот из последних: http://www.tpc.org/tpch/results/tpch_result_detail.asp?id=104081302

Внимательно медитируем над строчками
Total System Cost 669,239 US $
CPU: Intel Itanium2 1500MHz
# of CPUs: 16

Хочу такой КПК, массаракш. Я на нем в Ил-2 летать буду.

>2. База будет медленно обновлятся у конечных пользователей

>Получение паспорта будет осуществляться только после очередного обновления базы по всей стране.

Пользователь может умереть, не успев получить свидетельство о рождении.

>никто не мешает заказать разработку специализированного процессора под конретную задачу.

Закажите! Закажите! Процессор -- хорошему человеку Кеше из Зеленограда, а мне -- разработку базы данных.

С уважением, СИ
От tsa
К Sergey Ilyin (08.09.2004 15:23:17)
Дата 08.09.2004 18:03:04

Фигня.

Здравствуйте !

Вы не понимаете разницы в задачах.

1) Эти тесты иммтируют работу рельных сложных баз данных. Где выборка может идти зачастую по весьма сложным критериям.
2) Там делаются публикации ради рекордных показателей.

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

С уважением, tsa.
От Sergey Ilyin
К tsa (08.09.2004 18:03:04)
Дата 08.09.2004 18:09:55

Я когда писал ответ не знал, что задача _настолько_ ограничена.

>Поиск по уникальному ключу, которым будет номер паспорта, в базе с сотнями миллионов записей будет занимать секунды.
>А большего в местах проверки паспортов и не надо.

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

С уважением, СИ
От Алексей Мелия
К Sergey Ilyin (08.09.2004 15:23:17)
Дата 08.09.2004 17:31:57

Какая там была задача?

Алексей Мелия

Там по ключевому полю искали?
Или решали совершенно другую задачу не имеющею отношения к обсуждаемой теме?


http://www.military-economic.ru http://www.livejournal.com/users/alex_melia/
От Sergey Ilyin
К Алексей Мелия (08.09.2004 17:31:57)
Дата 08.09.2004 17:37:12

Там же на сайте все расписано.

>Там по ключевому полю искали?
>Или решали совершенно другую задачу не имеющею отношения к обсуждаемой теме?

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

На самом деле, я несколько лопухнулся -- дал ссылку на тест ТРС-Н. ТРС-С к нашему примеру больше подходит.

Но на самом деле -- я просто хотел продемонстрировать стоимость и характеристики машин, работающих с терабайтными базами данных :)

С уважением, СИ
От Алексей Мелия
К Sergey Ilyin (08.09.2004 17:37:12)
Дата 08.09.2004 17:53:53

Re: Там же...

Алексей Мелия
>На самом деле, я несколько лопухнулся -- дал ссылку на тест ТРС-Н. ТРС-С к нашему примеру больше подходит.

Я плохо понимаю по английски. Там есть сведения о времени затрачивамом на поиск записи по ключивому полю в 100-150 миллионов записей?


>Но на самом деле -- я просто хотел продемонстрировать стоимость и характеристики машин, работающих с терабайтными базами данных :)

А какое отношения имеет "террабайтность" к времени поиска по одному полю? Причем полю ключивому либо проиндексированному.


http://www.military-economic.ru http://www.livejournal.com/users/alex_melia/
От Sergey Ilyin
К Алексей Мелия (08.09.2004 17:53:53)
Дата 08.09.2004 18:06:57

Re: Там же...

>Я плохо понимаю по английски. Там есть сведения о времени затрачивамом на поиск записи по ключивому полю в 100-150 миллионов записей?

Думаю, что нет. Там тесты "задач, близких к реальности". На основании которых можно думать о конфигурации сервера.

>А какое отношения имеет "террабайтность" к времени поиска по одному полю? Причем полю ключивому либо проиндексированному.

А непосредственное. Объем таблиц напрямую влияет на объем индексов. Для 150 миллионов россиян получается индексный файл размером в 1.2 гигабайта (см. выше). Какая часть этого файла будет прочитана при обходе индекса по "бинарному дереву" -- надо думать. В конце рабочего дня, я уже не помню, где это искать :) Заметная часть, в общем. А дальше просто смотрим, сколько времени надо дисковой системе, чтобы прочитать эти сотни мегабайт. :)

С уважением, СИ
От Игорь Куртуков
К Sergey Ilyin (08.09.2004 18:06:57)
Дата 08.09.2004 18:16:45

Ре: Там же...

>А непосредственное. Объем таблиц напрямую влияет на объем индексов. Для 150 миллионов россиян получается индексный файл размером в 1.2 гигабайта (см. выше). Какая часть этого файла будет прочитана при обходе индекса по "бинарному дереву" -- надо думать.

B-Tree - это не "бинарное дерево", а "сбалансированное" (balanced tree). Затем, для предложенной задачи весь корень индекса будет в кэше, а индеx естественно clustered. Т.е. количество чтений с диска для поиска можно оценить как 2-4.
От Алексей Мелия
К Sergey Ilyin (08.09.2004 18:06:57)
Дата 08.09.2004 18:16:19

Re: Там же...

Алексей Мелия

>А непосредственное.

Никакого. Общий объем базы на время поиска не влияет. Важно только число записей и длина ключевого/индексного поля. То есть картинки во воемя поиска не зайдествуются.

>Для 150 миллионов россиян получается индексный файл размером в 1.2 гигабайта (см. выше). Какая часть этого файла будет прочитана при обходе индекса по "бинарному дереву" -- надо думать. В конце рабочего дня, я уже не помню, где это искать :) Заметная часть, в общем. А дальше просто смотрим, сколько времени надо дисковой системе, чтобы прочитать эти сотни мегабайт. :)

Число записей нужных для обхода помноженное на размер кластера файловой системы. Но конкретная реализация индекса может оказать очень сильное влияние.


http://www.military-economic.ru http://www.livejournal.com/users/alex_melia/
От Роман (rvb)
К Sergey Ilyin (08.09.2004 18:06:57)
Дата 08.09.2004 18:08:57

Re: Там же...

>А непосредственное. Объем таблиц напрямую влияет на объем индексов. Для 150 миллионов россиян получается индексный файл размером в 1.2 гигабайта (см. выше). Какая часть этого файла будет прочитана при обходе индекса по "бинарному дереву" -- надо думать.

в случае "деревянного" индекса - логарифмическая зависимость от объема.

S.Y. Roman ( Холмовцы: http://vif2ne.ru/holmovo/forum/ )
От Добрыня
К Sergey Ilyin (08.09.2004 15:23:17)
Дата 08.09.2004 17:01:48

Совсем народ обленился...

Приветствую!
Хотите, я Вам на обычном офисном писюке такую задачку решу? Всего-то - табличка из 150 000 000 записей. Всего-то - 150 000 000 файлов с картинками.

>Закажите! Закажите! Процессор -- хорошему человеку Кеше из Зеленограда, а мне -- разработку базы данных.

Дайте мне часть от упомянутой суммы, на которую надо медитировать :-)

С уважением, Д..
От Sergey Ilyin
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 18:00:18

С учетом ограниченности постановки задачи.

Серия/номер российского паспорта -- 10 цифр. 10 цифр, если мне не изменяет склероз -- это LongInt. Умножаем 8 байт на 150 миллионов -- получаем 1.2 гигабайта.

Вот. Это объем вашего индексного файла. Можно покурить и эту цифру.

Хотя, конечно, задача простого поиска "чего-то" по одному параметру в рид-онли базе -- легко решается средствами файловой системы. Но как всякие простые задачи, она лишена практического смысла.

С уважением, СИ
От ARTHURM
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 17:46:19

Re: Совсем народ

Добрый день!

Видится что БД какого нибудь амерского банка работающего с кредитками вполне соизмерима по объему. И несоизмерима по количеству разновидностей и частоте транзакций. Разве что без фотографий.

С уважением ARTHURM
От ID
К ARTHURM (08.09.2004 17:46:19)
Дата 08.09.2004 18:08:35

Re: Совсем народ

Приветствую Вас!


>Видится что БД какого нибудь амерского банка работающего с кредитками вполне соизмерима по объему. И несоизмерима по количеству разновидностей и частоте транзакций. Разве что без фотографий.

Вот только на писюках никто такие задачи там не решает , и даже на рисках стараются не делать, все больше на мейнфремах. Наш девиз - каждому ППСнику - по Рэптору!!!!! :-))))

С уважением, ID
От ARTHURM
К ID (08.09.2004 18:08:35)
Дата 08.09.2004 18:15:23

А кто сказал на писюках?

Добрый день!

В ларьке, где принимают кредитные карточки тож мейнфрейм за стенкой не стоит.
Так что задача сводится примерно к созданию информационной инфраструктуры как в США. Кстати полезная и без всяких е-паспортов задача :)

С уважением ARTHURM
От ARTHURM
К ARTHURM (08.09.2004 17:46:19)
Дата 08.09.2004 17:57:34

Кстати по количеству конечных пользователей наверное тоже (-)
От Бульдог
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 17:43:12

На что будем спорить?

Представляю обычный офисный писюк. Если решаете в установленное время - он достается Вам. Нет - с Вас ящик коньяку.
От Лейтенант
К Бульдог (08.09.2004 17:43:12)
Дата 08.09.2004 17:55:54

Проиграете ... (-)
От Бульдог
К Лейтенант (08.09.2004 17:55:54)
Дата 08.09.2004 18:04:24

ОК, могу и с Вами так же поспорить. Условия те же (-)
От Sergey Ilyin
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 17:29:22

"Гыыыыыыыы" (ц) Ну решите :)

>Приветствую!
>Хотите, я Вам на обычном офисном писюке такую задачку решу? Всего-то - табличка из 150 000 000 записей. Всего-то - 150 000 000 файлов с картинками.

Если вы решите задачу поиска в этой базе по... комбинации из 10 произвольных параметров (это если мы еще биометрию не учитываем) в разумные сроки -- не потребовав пары десятков гигабайт оперативной памяти и супернавороченной дисковой системы... Тогда IBM, Microsoft и Oracle зря курят свой бизнес-план.

С уважением, СИ
От И. Кошкин
К Sergey Ilyin (08.09.2004 17:29:22)
Дата 08.09.2004 17:41:20

Пусть для начала создаст базу данных на 150 записей с фотографиями. На офисном п (-)
От Николай Поникаров
К Sergey Ilyin (08.09.2004 17:29:22)
Дата 08.09.2004 17:36:54

В том-то и дело, что задача весьма ограниченная!

День добрый.

>Если вы решите задачу поиска в этой базе по... комбинации из 10 произвольных параметров

Требуется лишь найти запись по одному параметру, даже не по маске!
Будем искать данные по номеру паспорта.

Ессно, на запросы типа "показать всех ЛКН возраста от 20 до 30, рост 160-170, находящихся в розыске" не замахиваемся.

С уважением, Николай.
От Sergey Ilyin
К Николай Поникаров (08.09.2004 17:36:54)
Дата 08.09.2004 17:45:51

Слишком ограниченная, нет?

>Требуется лишь найти запись по одному параметру, даже не по маске!
>Будем искать данные по номеру паспорта.

Что нам это даст? Уверенность в том, что данный паспорт существует и выдан тому, кто его предъявил? Зачем -- основная проблема вовсе не поддельные, а незаконно выданные документы, нет?

С уважением, СИ
От Николай Поникаров
К Sergey Ilyin (08.09.2004 17:45:51)
Дата 08.09.2004 17:51:54

Заявлена авторами такая :)

День добрый.

Бумажный паспорт, в нем номер и ключ к шифру. Из базы вытягиваются данные по номеру, расшифровываются, сравниваются. Все.

>Что нам это даст? Уверенность в том, что данный паспорт существует и выдан тому, кто его предъявил? Зачем -- основная проблема вовсе не поддельные, а незаконно выданные документы, нет?

Я тоже думаю, что постановка задачи - самое слабое место этого проекта :)

С уважением, Николай.
От Banzay
К Николай Поникаров (08.09.2004 17:36:54)
Дата 08.09.2004 17:44:14

Естно...

Как пример в нашей конторе dosбаза на 30000 посетителей по паспортам поиск 10-15 сек... на 333 целероне...
От Алексей Мелия
К Banzay (08.09.2004 17:44:14)
Дата 08.09.2004 18:02:57

Вот отсюда и требования к суперсерверу

Алексей Мелия
>Как пример в нашей конторе dosбаза на 30000 посетителей по паспортам поиск 10-15 сек... на 333 целероне...

на 286 поиск в нормально написаной базе поиск будет происходить за доли секунды.

http://www.military-economic.ru http://www.livejournal.com/users/alex_melia/
От Алексей Мелия
К Banzay (08.09.2004 17:44:14)
Дата 08.09.2004 17:55:49

Re: Естно...

Алексей Мелия

>Как пример в нашей конторе dosбаза на 30000 посетителей по паспортам поиск 10-15 сек... на 333 целероне...

Поле проиндексированно?

http://www.military-economic.ru http://www.livejournal.com/users/alex_melia/
От Banzay
К Алексей Мелия (08.09.2004 17:55:49)
Дата 08.09.2004 18:00:41

неа... (-)
От Sergey Ilyin
К Banzay (08.09.2004 18:00:41)
Дата 08.09.2004 18:01:32

Еще бы. Было б проиндексировано -- искало б мгновенно :))) (-)
От И. Кошкин
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 17:19:23

Ну решите ради прикола. Мне даже интересно))) (-)
От ID
К Добрыня (08.09.2004 17:01:48)
Дата 08.09.2004 17:16:15

А при чем здесь лень?

Приветствую Вас!

>Хотите, я Вам на обычном офисном писюке такую задачку решу?

Может быть и решите, а может и нет. Но даже если и решите, напомню вам, что мощность "обычного" оффисного писюка существенно выше чем какого-нибудь палма или айпака.

> Всего-то - табличка из 150 000 000 записей.
Надеюсь табличку не в экселе будете делать? :-))

> Всего-то - 150 000 000 файлов с картинками.
Даже если по 10 к на картинку положить - на какой винчестер вы это все запихнете? По любому в обычные офисные 40-80 гигов не залезет.

С уважением, ID
От Добрыня
К ID (08.09.2004 17:16:15)
Дата 08.09.2004 17:43:05

Лень при том, что люди не видят дальше кончика носа

Приветствую!

Например, в упор не видят ограничений задачи и следующих из них частных решений (на несколько порядков более дешёвых и эффективных, чем покупка 16-процессорного шкафа) :-) Напомню наше ограничение: полное отсутствие необходимости вставки и индексирования записей - таблица формируется разовой операцией записи массива данных, таблица отсортирована заранее. Просто благодать для быстрого поиска нужной записи - даже методом половинного деления это займёт не более 28 операций, не говоря о том, что можно просто читать по адресу, если первичный ключ грамотно продуман. Очень похоже на работу с ГИС - там объёмы данных тоже очень и очень приличные, а карты работают быстро.

>>Хотите, я Вам на обычном офисном писюке такую задачку решу?
>
>Может быть и решите, а может и нет. Но даже если и решите, напомню вам, что мощность "обычного" оффисного писюка существенно выше чем какого-нибудь палма или айпака.

Ну а зачем пальмой ограничивать себя? Небольшого ноутбука хватит (конечно, картинок многовато - но малые диски с такими объёмами не за горами, год-два максимум).

>> Всего-то - табличка из 150 000 000 записей.
>Надеюсь табличку не в экселе будете делать? :-))

Могу просто в файл :-)

>> Всего-то - 150 000 000 файлов с картинками.
>Даже если по 10 к на картинку положить - на какой винчестер вы это все запихнете? По любому в обычные офисные 40-80 гигов не залезет.

Пока тут спорим, уже можно будет :-)
Я за прогрессом не слежу - но работаю с видео, свой писюк с полгода назад покупал, не самый крутой, и то больше сотни гигов. Думаю, уже сейчас гигов 500 - не проблема.

>С уважением, ID
С уважением, Д..
От ID
К Добрыня (08.09.2004 17:43:05)
Дата 08.09.2004 18:04:01

Ну когда на кончике носа фэнтези - тоже не здорово.

Приветствую Вас!
>Приветствую!

>Например, в упор не видят ограничений задачи и следующих из них частных решений (на несколько порядков более дешёвых и эффективных, чем покупка 16-процессорного шкафа) :-) Напомню наше ограничение: полное отсутствие необходимости вставки и индексирования записей - таблица формируется разовой операцией записи массива данных, таблица отсортирована заранее. Просто благодать для быстрого поиска нужной записи - даже методом половинного деления это займёт не более 28 операций, не говоря о том, что можно просто читать по адресу, если первичный ключ грамотно продуман. Очень похоже на работу с ГИС - там объёмы данных тоже очень и очень приличные, а карты работают быстро.

>>>Хотите, я Вам на обычном офисном писюке такую задачку решу?
>>
>>Может быть и решите, а может и нет. Но даже если и решите, напомню вам, что мощность "обычного" оффисного писюка существенно выше чем какого-нибудь палма или айпака.
>
>Ну а зачем пальмой ограничивать себя? Небольшого ноутбука хватит (конечно, картинок многовато - но малые диски с такими объёмами не за горами, год-два максимум).



Приветствую Вас!

>Ну а зачем пальмой ограничивать себя?

По условия вводной речь шла именно о PDA и ноутбук заведомо выпадает.

>Небольшого ноутбука хватит (конечно, картинок многовато - но малые диски с такими объёмами не за горами, год-два максимум).

С терабайтными винтами ? Года три в лучшем случае.

>>> Всего-то - табличка из 150 000 000 записей.
>>Надеюсь табличку не в экселе будете делать? :-))
>
>Могу просто в файл :-)

А как вы искать будете данные на PDA? В качестве примера моя маленькая базка на PDA. Число записей - 3000, время поиска - 3 секунды. Конечно мой псион старенький но ничего мощнее максимум чем на два порядка я не знаю, а обхем гипотетической базы будет больше на 5 порядков минимум.

>>> Всего-то - 150 000 000 файлов с картинками.
>>Даже если по 10 к на картинку положить - на какой винчестер вы это все запихнете? По любому в обычные офисные 40-80 гигов не залезет.
>
>Пока тут спорим, уже можно будет :-)

Да не видно таких винчестеров реальных на терабайт, тем более для мобильных устройств.

>Я за прогрессом не слежу - но работаю с видео, свой писюк с полгода назад покупал, не самый крутой, и то больше сотни гигов. Думаю, уже сейчас гигов 500 - не проблема.

Вообще-то ничего больше 250 нет пока.

С уважением, ID
От И. Кошкин
К ID (08.09.2004 18:04:01)
Дата 08.09.2004 18:12:41

На два порядка - это в сто раз (-)
От Лейтенант
К Добрыня (08.09.2004 17:43:05)
Дата 08.09.2004 17:54:57

А тут Вы правы

>Например, в упор не видят ограничений задачи и следующих из них частных решений (на несколько порядков более дешёвых и эффективных, чем покупка 16-процессорного шкафа) :-) Напомню наше ограничение: полное отсутствие необходимости вставки и индексирования записей - таблица формируется разовой операцией записи массива данных, таблица отсортирована заранее. Просто благодать для быстрого поиска нужной записи - даже методом половинного деления это займёт не более 28 операций, не говоря о том, что можно просто читать по адресу, если первичный ключ грамотно продуман. Очень похоже на работу с ГИС - там объёмы данных тоже очень и очень приличные, а карты работают быстро.

Есть еще пример - пресловутая телефонная база г.Москвы. По номеру телефона и фамилии ищет в нескольких миллионах записей моментально. На фоксе досовском написано влоб.