ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Новости Cache' сюда пожалуйста!
25 сообщений из 67, страница 1 из 3
  1  все
Новости Cache' сюда пожалуйста!
    #32289438
AndRUsha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AndRUsha
Гость
Очень бы хотелось узнать каких высот на данный момент достигла CACHE' и насколько она способна конкурировать с Oracle, MS SQL или DB2 по части "урывания" у них проектов.

Я понимаю, что тут уже достаточно написано по этому поводу, но всё же время летит и положение вещей меняется, так что объясните пожалуйста.
...
Рейтинг: 0 / 0
10.10.2003, 02:08
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32290242
Фотография riman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
riman
Участник
Тоже хотелось бы узнать объективное мнение людей работавших/видевших как работает CACHE'. На сайте cache.ru есть новости, но что - то уж они захлебываются в собачей радости от своего продукта, завышая (ИМХО) оценки быстродействия. Вот вам пример:
Код: plaintext
1.
Известны случаи перевода в Cach 233 ;  сложных приложений, которые ранее работали под управлением реляционных СУБД. Например, один из партнеров InterSystems перевел на Cach 233 ;  биллинговую систему для операторов сотовой связи. Переход осуществлялся следующим образом: сначала существующее приложение с минимальными изменениями переносится под управление Cach 233 ; . Приложение на первом этапе работает с Cach 233 ; , так же как и с реляционной СУБД. Опыт показывает, что даже в этом случае, система начинает работать быстрее. Далее ряд операций был переписан, с использованием прямого способа доступа к БД. На этом этапе удалось увеличить производительность критических операций в десятки и сотни раз.

10! 100! Аж дух захватывает. Хотя не указана СУБД, с которой они её сравнивали (мож Access? тогда конечно, они не соврали).
...
Рейтинг: 0 / 0
10.10.2003, 16:52
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32290301
Maksim UM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maksim UM
Гость
Работать с ней можно.
Конкурировать с Oracle, MS SQL или DB2 вполне может.
Но многое зависит от того, как ее использовать (надо понимать, как устроена БД для эффективного использования).
Удобно интегрируется с WEB.
По скорости, я создавал порядка 100.000.000 записей (около 4.5Гб) и
вполне комфортно себя чувствовал (Linux, P4 2.4, 512Mb). Но пока сам не попробуешь - не узнаешь объективно !-)
Из минусов - более сложно реализовать безопасность.
...
Рейтинг: 0 / 0
10.10.2003, 17:32
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32290505
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
Самые объективные оценки и компетентные мнения можно найти разумеется тут:\r
/topic/9021&pg=-1\r
\r
Рекомендую обратить внимание на информацию от Garya. \r
Он наиболее серьезно подошел к дисскуссии, не поленился почитать документацию а также провел тесты и пообщался с техсапортом из кеша. Реакция техсапорта очень интересна и показательна.\r
\r
За прошедшие 3 недели нкаких прорывов или революций в данной области не наблюдалось.\r
\r
Цитате, с сайта кеша "Известны случаи перевода в Caché сложных приложений..." уже как минимум года полтора. Нестареющая вещь. Еще лет 10 пролежит и будет выглядеть как новая. Если только сайт не загнется.
...
Рейтинг: 0 / 0
10.10.2003, 23:41
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32290617
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Maksim UM писал:По скорости, я создавал порядка 100.000.000 записей (около 4.5Гб) и
вполне комфортно себя чувствовал

Это чего, сравнение такое? По количеству записей?
А комфортно -это как? Вот прокладки рекламируют - говорят, если их использовать, то будешь комфортно чувствовать


Почти никто в глаза пока не видел ничего работающего на Кэше. Ну кроме конечно самих разработчиков - как обычно :)
Тут наша дружеская компания купила финансовую систему на Кэше. Типа -Кэш это теперь круто. Систему написала какая-то российская фирма. Ни одного внедрения до покупки у них не было. И ни одного и не стало - после покупки оказалось, что система г.... Кэш тут конечно не виновата, но.... Антиреклама однако :)
...
Рейтинг: 0 / 0
11.10.2003, 16:36
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32290974
Andrew_256
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew_256
Гость
2tygra:
Зная только Delphi+SQL можно конечно далеко уйти в сравнениях СУБД. Меня только удивляет как Вы, дорогой, не устали писать, что все кроме SQL 2000 - г..но.
Вопрос: какие СУБД вы тестировали на предмет производительности
для Вашей конкретной задачи и каие результаты Вы получили? Если тестировали - результат в студию!
Я, например, тестировал Cache и MS SQL на вставку записей через ODBC провайдер. Т.е. один и тот же С++ код всталяет 1000 записей формата Время-Значение (без индексов). Код абослютно одинаковый - менял только имя провайедра. Cache' = в 50(!) раз быстрее.
Пробовал все возможные (BKM - best known methods) варианты.
Единственное, где мне удалось обогнать Cache' - при одновременной вставке более 500 записей с помощью BULK INSERT (отсутствие транзакций в MS SQL!). Но для обычной OLPT системы - результат налицо.
Вообще, готов поспорить, что для любых 2-х random СУБД, можно реализовать
одну задачу с разной (+-2Х) производительностью. Поэтому все тесты, кроме 2-х толстых идентичных клиентов - лажа, которые тоже ни о чем не говорят.
Да и эти говорят о производиельности SQL оптимизатора и ODBC драйвера.
...
Рейтинг: 0 / 0
13.10.2003, 10:07
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32291041
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Обычно сравнивают наоборот - по скорости выборки данных. :)
А вставка - это ни о чем. В dbf она быстрее всех, однако это ничего не говорит.

ЗЫ Не помню, чтобы я говорил, что все кроме SQL 2000 - г..но.
Оракл -хорошая БД. :) Просто сейчас на нем я не работаю. Будет возможность или необходимость - будем использовать. Сейчас хватает MS SQL на все 100%.
А Cache - никто нигде ее не видел, ничего на ней нет, и в связи с этим слова о том, что она круче всех - это как результаты MySQL на их сайте.

-- Tygra's --
...
Рейтинг: 0 / 0
13.10.2003, 11:41
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32293496
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Andrew_256
>Вообще, готов поспорить, что для любых 2-х random СУБД, можно реализовать одну задачу с разной (+-2Х) производительностью. Поэтому все тесты, кроме 2-х толстых идентичных клиентов - лажа, которые тоже ни о чем не говорят. Да и эти говорят о производиельности SQL оптимизатора и ODBC драйвера.

Странная логика, как второе предложение следует из первого? А толстые клиенты не могут быть написаны (+-2Х)? Обработка данных на сервере тоже полезная штука, непонятно только почему ее нельзя тестировать. На том же TPC.ORG есть тесты на этот счет.

Кстати SQL оптимизатор при добавлении строк в обсуждаемых случаях не участвует. Так что упоминаемые insert тесты к "производительности оптимизатора" никакого отношения не имеют. Оптимизатор тестируется на аналитических запросах (OLAP), как раз тех, которые по Вашему утверждению - полная лажа.

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

>Но для обычной OLPT системы - результат налицо.

А что такое OLPT система? Объясните популярно, а то я кроме скл и дельфи похоже и вправду ничего не знаю.
...
Рейтинг: 0 / 0
15.10.2003, 01:15
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32293580
Andrew__256
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew__256
Гость
автор писал:Обычно сравнивают наоборот - по скорости выборки данных. :)
А вставка - это ни о чем. В dbf она быстрее всех, однако это ничего не говорит.
Если БД не успевает вставлять, то читать будет нечего. А с dbf сравнение некорректно - другая технология. Cache и MS SQL оба CS, оба поддерживают транзакции и блокировки, поэтому их сравнивать можно, тем более, что вставлял я одним и тем же клиентом через ODBC.

автор писал:Странная логика, как второе предложение следует из первого? А толстые клиенты не могут быть написаны (+-2Х)? Обработка данных на сервере тоже полезная штука, непонятно только почему ее нельзя тестировать. На том же TPC.ORG есть тесты на этот счет.
Я имел ввиду, что если взять одно приложение, где вся бизнес-логика зашита на клиенте (представим, что используется только ANSI SQL), подставить 2 разных СУБД под него без изменения кода на клиенте и сравнивать скорость, то это может быть достаточно корректное сравнение для ДАННОГО КОНКРЕТНОГО случая.
Что касается серверной обработки, то здесь результаты зависят на 100% от кривизны рук, поэтому единственными корректными являются тесты СУБД от ее же производителя - только они могут утверждать, что они выжали из СУБД все, что можно.

автор писал:Кстати SQL оптимизатор при добавлении строк в обсуждаемых случаях не участвует. Так что упоминаемые insert тесты к "производительности оптимизатора" никакого отношения не имеют. Оптимизатор тестируется на аналитических запросах (OLAP), как раз тех, которые по Вашему утверждению - полная лажа.

Фраза про оптимизатор SQL относится к случаю толстого клиента.


автор писал:А что такое OLPT система? Объясните популярно, а то я кроме скл и дельфи похоже и вправду ничего не знаю.

Опечатка - OLTP.

Что касается Cache - не хочу тратить время на споры и доказательства - это работа Интерсистемс. Просто хотел сказать, что форум называется "Сравнение СУБД", а не "Сравнение СУБД, которые знает Tygra". Если в Америке вы спросите, что такое Delphi, 90% программистов вам не ответят. Но это не значит, что Delphi плохая система.
Если не знаком с СУБД - помолчи, выскажутся те, кто знаком.
...
Рейтинг: 0 / 0
15.10.2003, 08:56
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32293920
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
писал:Если не знаком с СУБД - помолчи, выскажутся те, кто знаком

Я аккумулировал все их высказывания на этом форуме
Вообще информация про Cache очень похожа на рекламу по Дарьял-ТВ всяких чудо-ножей, массажеров и т.п.: никто этого не видел, но покупать надо, потому что хорошее. :)

А про скорость вставки - не переживайте, успеем вставить все, что нужно. Кстати, Cache' = в 50(!) раз быстрее. - это сколько в записях? И как вставлялось? На какой (каких) машине?

Я вот специально проверил - 1000 записей построчно - 5-7сек, всем скопом - 3сек.


-- Tygra's --
...
Рейтинг: 0 / 0
15.10.2003, 12:34
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32294262
n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
n
Гость
Код: plaintext
1.
Если БД не успевает вставлять, то читать будет нечего. А с dbf сравнение некорректно - другая технология. Cache и MS SQL оба CS, оба поддерживают транзакции и блокировки, поэтому их сравнивать можно, тем более, что вставлял я одним и тем же клиентом через ODBC.


ну право вы меня насмешили. спасибо.
...
Рейтинг: 0 / 0
15.10.2003, 15:33
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32294709
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Andrew__256

>Фраза про оптимизатор SQL относится к случаю толстого клиента.

Опять мимо. Если клиент толстый, то в нем и происходит в вся обработка и оптимизация (именно потому он и называется толстым), а база обрабатывает только простые инсерты и селекты. SQL оптимизатор по-прежнему почти не работает.

>Что касается серверной обработки, то здесь результаты зависят на 100% от кривизны рук, ...

Результаты всегда зависят от кривизны рук, даже если не написано ни одной строчки кода. Можно неправильно проинсталлировать, можно не создать нужный индекс и т.д. Следует ли из этого, что никакие разные продукты никогда сравнивать нельзя?

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

К сожелению производитель кеша не производит мсскл сервер. С другой стороны насколько мне известно Интерсистемс и мелкософт не собираются устраивать соревнование серверов, а в соревновании, устроеном TPC.ORG производитель кеша почему-то не участвоует (интересно почему?). Так что следуя Вашей логике о сравнительных тестах нужно забыть навсегда.

Но основная-то проблема в том, что высокая производительность это хорошо, но далеко не все, что требуется от СУБД.
...
Рейтинг: 0 / 0
15.10.2003, 23:44
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32294745
Andrew_256
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew_256
Гость
2с127:
автор писал:Опять мимо. Если клиент толстый, то в нем и происходит в вся обработка и оптимизация (именно потому он и называется толстым), а база обрабатывает только простые инсерты и селекты. SQL оптимизатор по-прежнему почти не работает.
Да, точно. Толстый клиент начинает с парсинга SQL, затем строит план запроса, выбирает индекс, по которому нужно бежать, и выполняет операции join/union и т.п. :-)))))
Если вы так думаете - подумайте еще раз.

автор писал:Но основная-то проблема в том, что высокая производительность это хорошо, но далеко не все, что требуется от СУБД.
Вот тут я с вами согласен, поэтому и говорю, что даже случай толстого клиента - хороший тест для ДАННОЙ КОНКРЕТНОЙ задачи.

автор писал:А про скорость вставки - не переживайте, успеем вставить все, что нужно. Кстати, Cache' = в 50(!) раз быстрее. - это сколько в записях? И как вставлялось? На какой (каких) машине?
Я вот специально проверил - 1000 записей построчно - 5-7сек, всем скопом - 3сек.

Гонял я это на PIII-750 SCSI. Но так как я использовал одного и то же приложение и один и тот же компьютер, то это не очень важно.

А по времени: вставка 500 записей построчно у меня на SQL была порядка 3 сек, а в Cache - 120 мсек. Т.е. где-то в 30 раз (виноват, ошибся). Варианты разные.
При этом я и там и там использовол ODBC драйвер, что для Cache не есть оптимальный вариант.
Единственное, где мне удалось "порвать" Cache - это на записях бОльших объемов (5000 за один раз) через BULK INSERT (из-за ограничения в 32К на размер строки в Cache - клиент не может передать бОльшую порцию за один раз. Точнее может, но уже нужно напрягаться).
Но с BULK INSERT нельзя использовать транзакции.

БОльше на эту тему общаться мне не хочется. Скажу лишь, что понимаю, что MS SQL не предназначена для использования как real-time СУБД, поэтому данные измерения относятся также к одной КОНКРЕТНОЙ задаче и поэтому делать выводы о том, что Cache лучше в принципе - неправильно.
...
Рейтинг: 0 / 0
16.10.2003, 03:30
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32294773
Ermak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ermak
Участник
Вставка записей - это конечно очень важно

Но кто-нибудь сравнивал скорость выполнения отчетов для каши и sql_серверов? Желательно на данных большого объема.
...
Рейтинг: 0 / 0
16.10.2003, 06:04
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32296026
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Andrew_256

>Да, точно. Толстый клиент начинает с парсинга SQL, затем строит план запроса, выбирает индекс, по которому нужно бежать, и выполняет операции join/union и т.п. :-)))))
Если вы так думаете - подумайте еще раз.

Еще раз очень медленно специально для любителей кеша:
"... а база обрабатывает только простые инсерты и селекты". Если клиент перекладывает обработку данных на базу (а сложный селект есть обработка данных), то тостым его уже назвать нелзья и по Вашей же посылке тест получается некорректным. Ведь сложный селект можно написать "разной (+-2Х) производительностью". Простые запросы тоже оптимизируются, но в этом участвует очень небольшой кусок оптимизатора. Так что пытаться тестировать оптимизатор на толстом киленте несерьезно.

c127> Но основная-то проблема в том, что высокая производительность это хорошо, но далеко не все, что требуется от СУБД.

Andrew_256> Вот тут я с вами согласен, поэтому и говорю, что даже случай толстого клиента - хороший тест для ДАННОЙ КОНКРЕТНОЙ задачи.

Тут речи о тестах уже не было. Речь шла о безопастности и целостности данных. В РДБМС на этот счет есть целая наука.

Еще одна важная вещь, как тут правильно заметили - скорость получения отчетов. Причем не только скорость отработки запросов сервером, но и скорость написания запроса программистом.
...
Рейтинг: 0 / 0
17.10.2003, 01:08
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32296180
bushmen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bushmen
Участник
2 Andrew_256:

А с dbf сравнение некорректно - другая технология. Cache и MS SQL оба CS, оба поддерживают транзакции и блокировки, поэтому их сравнивать можно

Да? А я с сайта intersystems вычерпал другую информацию, что Cache - постреляционная СУБД, а значит, с MS SQL - не одно и то же!

Или Intersystems нас всех за нос водит и Cache - это всё же реляционная БД?
...
Рейтинг: 0 / 0
17.10.2003, 09:56
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32296250
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Что значит "постреляционная"? Это хуже чем реляционная или лучше? Ну назвали они её "постреляционной" - что, давайте будем вестись на это? Они могли назвать ее "суперреляционной" или "недореляционной" - это всего лишь ИХ НАЗВАНИЕ.

Когда говорят, что СУБД является реляционной - это говорит о том, что она базируется на конкретной МАТЕМАТИЧЕСКОЙ модели. А все остальное -"пост...", "супер..." , "недо..." - от лукавого....маркетинг.
...
Рейтинг: 0 / 0
17.10.2003, 10:31
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32296257
bushmen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bushmen
Участник
>U-gene
Я с тобой не спорю. Я просто этим хотел сказать, что сами создатели Cache говорят, что нельзя ее сравнивать с SQL
...
Рейтинг: 0 / 0
17.10.2003, 10:34
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32299239
ArchiMage
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ArchiMage
Участник
Про большие объемы:

Я закачал из Oracle в Cache' две таблицы - счета (13000 записей) и выписку(2000000 записей), вязка выписки два раза к таблице счетов и запрос по вязке осуществляется сравнимо с Oracle по быстродействию, только Cache занимает в памяти 64 Мбайта, а Oracle - 640, вот такой вот опыт. Подобные запросы - обычная вещь для нашей системы.

Проверял на Cache 4 и Oracle 8.1.6 оба под Win2000.

Скоро, м.б. проверю на Cache 5 и Oracle 9.0.2, оба под Linux.

Самое большое удобство Cache' - в прямой работе с объектами в Java-клиентских приложениях, чего нет в Oracle, а в MSSQL-е и подавно. Хотя Oracle потихоньку продвигается к этому, скоро догонит :) В 9-ке по крайней мере уже напрямую говорится - почему бы не писать stored procedures & triggers in Java... Тенденция, однако :)
...
Рейтинг: 0 / 0
21.10.2003, 06:58
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32299266
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Zaxx
Гость
2 ArchiMage

>Самое большое удобство Cache' - в прямой работе с объектами в Java-клиентских приложениях, чего нет в Oracle, а в MSSQL-е и подавно.

Можно поподробнее ? Сервер работает с объектами в Java-КЛИЕНТСКИХ приложениях? Как? Зачем серверу что-то делать с клиентским приложением ?

>Хотя Oracle потихоньку продвигается к этому, скоро догонит :)
К чему ? К прямой работе с объектами в Java-клиентских приложениях ???

> В 9-ке по крайней мере уже напрямую говорится - почему бы не писать stored procedures & triggers in Java...

Не говориться, а делается, и не в 9-ке, а уже в 8-ке.
...
Рейтинг: 0 / 0
21.10.2003, 08:13
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32300625
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 ArchiMage
>Я закачал из Oracle в Cache' две таблицы - счета (13000 записей) и выписку(2000000 записей), вязка выписки два раза к таблице счетов и запрос по вязке осуществляется сравнимо с Oracle по быстродействию, только Cache занимает в памяти 64 Мбайта, а Oracle - 640, вот такой вот опыт. Подобные запросы - обычная вещь для нашей системы.

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

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

А 640 MB сейчас никого не испугаешь. Оракл вообще откусывает память про запас и потом в ней работает.
...
Рейтинг: 0 / 0
22.10.2003, 04:31
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32301024
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
У нас MS SQL имеет 4 Гб и не жалуется. И что? Памяти кому-то жалко?

-- Tygra's --
...
Рейтинг: 0 / 0
22.10.2003, 11:17
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32301615
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
Да вообще то жалко, но куда деваться ...
...
Рейтинг: 0 / 0
22.10.2003, 15:16
| Ответить | Цитировать | Написать  
Новости Cache' сюда пожалуйста!
    #32302007
Little
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Little
Гость
Хехе, ключевое слово "на фоне инсертов и апдейтов других юзеров"\r
\r
Мне чего-то кэшологи так и не ответили на вопрос :)\r
\r
/topic/9021&pg=11#380150
...
Рейтинг: 0 / 0
22.10.2003, 17:32
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Новости Cache' сюда пожалуйста!
    #32959844
KostyaNext
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KostyaNext
Участник
Andrew_2562tygra:
Я, например, тестировал Cache и MS SQL на вставку записей через ODBC провайдер. Т.е. один и тот же С++ код всталяет 1000 записей формата Время-Значение (без индексов). Код абослютно одинаковый - менял только имя провайедра. Cache' = в 50(!) раз быстрее.
Пробовал все возможные (BKM - best known methods) варианты.
Единственное, где мне удалось обогнать Cache' - при одновременной вставке более 500 записей с помощью BULK INSERT (отсутствие транзакций в MS SQL!). Но для обычной OLPT системы - результат налицо.


Ну ты сказочник, Андрюшка. Я тоже много тестировал MSSQL и Cache. Так вот, практически нет операций, на которых Cache был бы быстрее. Да, работать с обьектами иногда удобнее, но скорость - ужасно.

Например, одна интересная особенность у Cache. Допустим надо сделать выборку. Скажем, в MSQL запрос выполняется 30 сек и возвращает 1000 записей, чтение набора занимает меньше 1 сек. В Cache такой запрос выполняется чуть дольше, зато чтение записей (даже не открытие соответствующие обьектов а просто чтение полей .Get() рекордсета) занимает минимум в 20-30 раз больше. Причем, при росте базы это время растет офигенно.

В частности, была реальная БД по регистрации состояний устройств, (устройство, имя,значение). Причем данные не удалялись а непрерывно росли. Если в начале эксплуатации удавалось записать до 100 состояний в секунду, то через месяц, когда количество обьектов (записей) выросло до неск. сот тысяч, удавалось вставлять максимум 5 состояний в секунда, и это при почти 100% загрузке дисковой подсистемы и CPU!
...
Рейтинг: 0 / 0
14.03.2005, 23:39
| Ответить | Цитировать | Написать  
25 сообщений из 67, страница 1 из 3
  1  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Новости Cache' сюда пожалуйста!
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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