Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10 11   вперед  Ctrl      все
 Re: Слабые стороны Cache & SQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31621
Ну сертифицирующая контора вааще-то называецца ЛОНИИС
21 май 06, 20:31    [2689078]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс). Там больше параметров используется. Один из них - длина квитанции. Печать то производится не на рулонную бумагу, а на (жаргонно) листинг. Поэтому нужно знать как сформатировать квитанции, что бы доставщики смогли их быстро и просто разделить. Вот вычисление длины квитанции и занимает много времени. Там не только счета к оплате, но и извещения и реклама, и еще какие либо тексты присутсвуют. Причем для каждого клиента свой набор.
21 май 06, 20:35    [2689086]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Изопропил
Ну сертифицирующая контора вааще-то называецца ЛОНИИС


Ну пусть и так.. что с того? Чем хуже ЛНИИСА?
21 май 06, 20:37    [2689093]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@escape.ru
Да нет.. зачем придумывать?

Хммм... То ли я не по-русски говорю, то ли Вы не по-русски понимаете.
Еще раз. Откуда взялось утверждение о сертификации на 10 млн, если в статье приведены только факты о сертификации на "до 500 тысяч абонентов"? Я вот Вас и спрашиваю - зачем придумывать?

Статья устарела уже, но всё там правда.

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

Я разговаривал с одним из разработчиком этой системы. Сертифицировал её ЛНИИС (Ленинградский НИИ связи).

Да по мне хоть бы её Карабас Барабас сертифицировал. Вы на знакомых не кивайте, лучше ответьте на вопрос - откуда взялась сертификация на 10 млн.? Это Вы сами выдумали, или Ваш знакомый разработчик?

У меня нет причин не доверять тем людям.

А у меня нет причин им доверять.
Пока что общедоступные факты - это сертификация на обслуживание сетей емкостью до 500000 номеров. Зачем Вы это число в двадцать раз увеличили - непонятно.
21 май 06, 20:39    [2689097]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс).

В статье вижу слова:
"... Сортировка всех абонентов по адресам для печати квитанций... "
Вы пытаетесь утверждать, что это не сортировка по адресам.
ЛОЛ.
21 май 06, 20:41    [2689102]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс).

В статье вижу слова:
"... Сортировка всех абонентов по адресам для печати квитанций... "
Вы пытаетесь утверждать, что это не сортировка по адресам.
ЛОЛ.


Именно это я и утверждаю.

>>>Да по мне хоть бы её Карабас Барабас сертифицировал.

А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость.
21 май 06, 20:46    [2689109]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
>>>Да по мне хоть бы её Карабас Барабас сертифицировал.

А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость.

А зачем тогда ссылку на штатью было приводить?
Так бы и заявили сразу, мол одна бабка сказала, что на 10 миллионов (и более), но слова бабки ничем подтвердить не можете.
21 май 06, 20:48    [2689113]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?
21 май 06, 20:49    [2689118]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?

А это из штатьи, однако. В которой все правда.
21 май 06, 20:50    [2689124]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?

А это из штатьи, однако. В которой все правда.


аа.. да.. есть там такое.. перебор с рекламоу..
Но всё равно не пойму я вас что то..

Что Вы хотите сказать? Можете в паре абзацев изложить?
21 май 06, 20:54    [2689138]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Но всё равно не пойму я вас что то..

Фсе, это финиш...
Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете?

Вопрос:
Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

Если в вопросе Вам какое-то слово не понятно - откройте словарь живого великорусского языка Владимира Даля. Если все равно не понятно - это будет Вашим домашним заданием.
21 май 06, 20:59    [2689152]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31621
Сертификация - дело серьёзное.
Нет в природе такой сертифицирующей конторы -ЛНИИС.

Следовательно можно писать всё что угодно.
21 май 06, 21:00    [2689156]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
Но всё равно не пойму я вас что то..

Фсе, это финиш...
Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете?

Вопрос:
Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

Если в вопросе Вам какое-то слово не понятно - откройте словарь живого великорусского языка Владимира Даля. Если все равно не понятно - это будет Вашим домашним заданием.


Товарисч, спуститесь с небес. Мания величия - симптом.

>>Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

Информация взята со слов разработчиков. Документальным подтверждением не располагаю.
21 май 06, 21:01    [2689157]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Изопропил
Сертификация - дело серьёзное.
Нет в природе такой сертифицирующей конторы -ЛНИИС.

Следовательно можно писать всё что угодно.


ЛОНИИС конечно.. я неправильно назвал его раньше.
ЛОНИИС - Ленинградский Отраслевой Научно-исследовательский институт связи
21 май 06, 21:03    [2689159]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
Информация взята со слов разработчиков. Документальным подтверждением не располагаю.

И почему я не удивлен?
Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые.

То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов...
21 май 06, 21:06    [2689165]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
Информация взята со слов разработчиков. Документальным подтверждением не располагаю.

И почему я не удивлен?
Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые.

То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов...


Какие слухи то?
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.
21 май 06, 21:19    [2689189]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
yww@escape.ru
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.


Скажу по секрету - туда постить может все кому не лень - можно даже запостить что Орловская ГТС отказалась от использования Каше.



Пришли новость не от Инфосис
22 май 06, 08:05    [2689596]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
http://rusmetall.orel.ru
22 май 06, 09:23    [2689706]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Lepsik
yww@escape.ru
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.


Скажу по секрету - туда постить может все кому не лень - можно даже запостить что Орловская ГТС отказалась от использования Каше.



А кроме Вас, это кому нибудь надо?
Вот ещё ссылки. Пофантазируйте про них.

http://www.connect.ru/article.asp?id=6341

http://www.pcweek.ru/?ID=294287&4Print=1
http://www.it-daily.ru/?ID=174340&Year=2003&Month=6&Day=17

А вот база сертификатов
http://svcons.ru/cgi-bin/sert2006/sert_cnt.cgi?acs=&nomcat=0&date=All&poisk=%CE%D0%C5%CB-%CC
22 май 06, 10:09    [2689874]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает
Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО


А это :
"Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2."
смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 )
22 май 06, 11:36    [2690417]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Если действительно все правда об испытаниях на 50 млн, то разработчики просто молодцы. Снимаю шляпу.

Однако, тесты системы и тесты движка базы данных не одно и то же.
Не секрет что в мире биллинговых систем не много оптимальных решений как по стуктуре базы так и по логике приложения. Знаю я одну систему не буду говорить как называется где биллинг работает вабще с плоскими файлами, буквально выгружает все из базы в файл поднимает все в память считает записывает в другой файл и грузит обратно в базу. Полет архитекторской мысли не правда ли. И ничего продается система. Самый большой сайт 2.5 млн абонентов, у которых не только обычные телефоны с количеством разговоров вычесленным по формулам каких то нии (знаю как они сертификаты выдают, да там стандарты небось 80-х годов, странно что на 100млн не провели испытания), но и линии доступа в инет и т.п.

Однако это не позволяет нам судить о качестве рдбмс оракл. Если бы проводилась такая параллель я бы сказал оракл дерьмо ничем не лучше аксеса.

Точно так же то что на каше создан супер удачный биллинг не дает возможности утверждать что каше 20 раз быстрее чем любой рдбмс.

да и выигрыш по размеру базы в 2 раза это не слишком много. если б хотыя бы в 5. а так ну купишь себе в 2 раза больше винтов, слава богу с этим нет проблемы

так что давайте кашисты не изворачивайтесь а делайте придложенный тест

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
22 май 06, 12:24    [2690726]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>>Однако, тесты системы и тесты движка базы данных не одно и то же.

Трудно не согласиться

>>>так что давайте кашисты не изворачивайтесь а делайте придложенный тест

Смысл в таких действиях может быть только в случае, когда тестеру нужно принять решение о выборе СУБД.. вот пусть автор топика и тестирует. Остальным - вряд ли это нужно.
22 май 06, 12:50    [2690894]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
yww@escape.ru
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает
Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО


А это :
"Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2."
смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 )


Если это правда, то я только радуюсь. По крайней мере есть ориентиры на скорость топовых решений.

А относительно оборудования - ну реально было 12, но их логи фиксировали что только на 2х была работа. Ок. Если так строится беседа, то СБОСС может написать - да у нас из 72 процов ваще только один чуть чуть юзался.

Не серьезно. Взяли бы двухпроцессорный Зеон и задали бы жару. А так...

А за

... и получили многомерные скоростные достижения мирового масштаба.


надо назначать изнасилование в особо извращенной форме :)
22 май 06, 13:18    [2691121]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Чернышев Андрей Леонидович
Сам дурак.

Чернышев Андрей Леонидович
На мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres.
Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы".
"Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных.


1. хорошо известно в каких случаях индексы надо использовать а в каких нет. 2. они отлично вписываются в модель: меньше нормализации - больше скорость и наоборот.
3. таким образом индексы это материализованные представления данных 4. отношения индексов дублируют отношения таблиц т.к дублируют данные.
5. индексы не храняться в отдельной субд и запросы на индексы могут быть составлены разработчиком.

можно так и дальше, но видно Ваши белые пятна в понимании рдбмс невосполнимы изначально

автор

И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД.

аргументы в студию, пока что аргументов не вижу



автор
Специалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится).

а по-моему последователи алтернативных направлений реализации сексуальных желаний подругому называются
22 май 06, 16:17    [2692129]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

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

главный вывод: это, как я уже говорил, несерьезный тест. ни оборудование,
ни загруженность СУБД, ни размерность записей не уравнены. разве можно делать какие-то серьезные выводы?

С уважением. Сергей
22 май 06, 17:06    [2692479]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить