Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsaКлассовое хранение используем только в новых задачах. Основной движок использует свое хранение. Значит надо смотреть что с движком. Серьезно, я на обычной рабочей машинке в 800 Mhz, памятью 128 и IDE винтом в 40Gb разбрасываю 1 миллион записей (индексы + данные) за 20-30 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:08 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov , ты думаеш у нас все долго считается? Когда запрос/форма/расчет выполняется не более чем за 5 минут, мало кого волнует как написан текст программы... А вот когда ведется расчет показателей для статистики (что-то там тыщами штук меряется), да по областной БД! А это, надо сказать, писали приверженцы точек и не стандартного хранеия данных в классах (для пущего ускорения)... Там расчет запускают "на ночь". И не думаю, что на точках они там получили большое ускорение... ---------- Cache for Windows (Intel) 2007.1 (Build 369) Fri Jun 15 2007 15:25:42 EDT Cache for Windows NT (Intel) 5.0.20 (Build 6305) Fri Sep 16 2005 11:54:10 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:16 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov krvsa Фома , как было уже замечено ранее, все будет тормозить HDD. Т.ч. я за читабельность текстов программ. Прошлый раз смолчал, сейчас не буду уже. Откуда такие мыслишки, если не секрет? Есть какие-то конкретные выкладки? Практика. Так как БД используется как правило для хранения очень большого числа данных, то при одновременной работе хотя бы сотни пользователей, какие бы вы дисковые системы не ставили, все равно будет висеть на нем родном. А на проце будет висеть только если на слабой машине и с маленьким объемом данных работает 1-2 человека. Но при чем тогда тут оптимизация точки-скобки? Вы действительно считаете, что при выборке из 200Гб базы (а ведь это даже не так уж много) главная проблема будет в проце? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:28 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsa Там расчет запускают "на ночь". И не думаю, что на точках они там получили большое ускорение... интересно было бы узнать за сколько времени тоже самое сделали бы "традициооные" СУБД. Что-то не слышал, чтоб в SQL сутками получали отчеты, а здесь - сплошь и рядом, и это при всем быстродействии Каше. Может дело именно в программистах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:31 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Вы действительно считаете, что при выборке из 200Гб базы (а ведь это даже не так уж много) главная проблема будет в проце? Главная проблема будет в структуре БД и программах, а также размере кэша, ну и проценте попадания туда нужных блоков, что опять приводит нас к структуре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:36 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Угу. Структуры+алгоритмы. А точки-скобки не дадут и доли процента скорости, я думаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:39 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsaты думаеш у нас все долго считается? А вот когда ведется расчет показателей для статистики (что-то там тыщами штук меряется), да по областной БД! А это, надо сказать, писали приверженцы точек и не стандартного хранеия данных в классах (для пущего ускорения)... Там расчет запускают "на ночь". И не думаю, что на точках они там получили большое ускорение... Вот теперь думаю, что ОЧЕНЬ долго. Тыщи штук? Где-то очень большие косяки в БД. Это не пример неудачного использования подхода к программированию, только к структурированию БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:41 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Тут рассуждать можно долго... ceshka , х/з как бы себя повели "традиционые" СУБД... Я даже не разрабатывал ту задачу... Но самое прикольное (для меня), что ее делали наши т.с. "ускорители". Я-то приверженец самого "медленого" (процедурного) подхода. ---------- Cache for Windows (Intel) 2007.1 (Build 369) Fri Jun 15 2007 15:25:42 EDT Cache for Windows NT (Intel) 5.0.20 (Build 6305) Fri Sep 16 2005 11:54:10 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:41 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
авторинтересно было бы узнать за сколько времени тоже самое сделали бы "традициооные" СУБД. Что-то не слышал, чтоб в SQL сутками получали отчеты, а здесь - сплошь и рядом, и это при всем быстродействии Каше. Может дело именно в программистах? Как вы могли бы уже заметить хотя бы по этому же топику, каше предостявляет множество способов сделать одно и то же разными способами. В том числе наворотить такого, чего наворотить на другой СУБД ну просто не представляется возможным Ну то есть именно то, что вы и имеете ввиду: да, дело в программистах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:43 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovТыщи штук? Это количество показателей меряется тыщами. А картотек и записей вних конечно гораздо больше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:44 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.да, дело в программистах. Абсолютно точно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 14:45 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsa Sergei ObrastsovТыщи штук? Это количество показателей меряется тыщами. А картотек и записей вних конечно гораздо больше... А конкретней? Миллионы? Десятки миллионов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:01 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Угу. Структуры+алгоритмы. А точки-скобки не дадут и доли процента скорости, я думаю Не надо думать, что "точки-скобки" не играют роли. Особенно когда это дело гоняется циклом на баальшой куче данных. Вон как у krvsa . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:03 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovА конкретней? Миллионы? Десятки миллионов? Да кто их считал... Сами-то картотеки ограничиваются 100 тысяч карточек, но вних есть подтаблицы, которые связаны с другими таблицами и т.п... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:06 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsa Sergei ObrastsovА конкретней? Миллионы? Десятки миллионов? Да кто их считал... Сами-то картотеки ограничиваются 100 тысяч карточек, но вних есть подтаблицы, которые связаны с другими таблицами и т.п... Плохо, что не считали. Мне бы хотелось оценить объемы. У меня всего лишь 100 млн. база, с которой можно сделать все что угодно в пределах... ну не знаю, минут 20 наверно. Потому и спрашиваю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:12 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovМне бы хотелось оценить объемы. Не получится... У вас ведь свое хранение данных, у нас свое... Да и задачи ваши и наши БД решают разные... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:15 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsa Sergei ObrastsovМне бы хотелось оценить объемы. Не получится... У вас ведь свое хранение данных, у нас свое... Да и задачи ваши и наши БД решают разные... А это неважно. Я ведь не сравниваю структуры и задачи. Я сравниваю объемы. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:17 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovЯ сравниваю объемы. :) Этого не достаточно... В таблице можно хранить: - "длиные" поля - она будет большего объема - много записей (например поступившие платежи на телефоны) - она будет большей по количеству записей Но особого "анализа" таких таблиц не сделаеш. Либо он и не требуется... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:21 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
krvsa Sergei ObrastsovЯ сравниваю объемы. :) Этого не достаточно... В таблице можно хранить: - "длиные" поля - она будет большего объема - много записей (например поступившие платежи на телефоны) - она будет большей по количеству записей Но особого "анализа" таких таблиц не сделаеш. Либо он и не требуется... Ну почему же? Вы даже не представляете сколько информации идет по телефонным звонкам к примеру. И все это можно и нужно анализировать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:24 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovВы даже не представляете сколько информации идет по телефонным звонкам Я с этим и не спорю... Просто привожу примеры т.с. "простых" таблиц с большими объемами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 15:27 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Уж не знаю как там с скобками vs точки - но вот количество строк (Антон Умников 2000й год) на скорость "влияет" - а скобки они того в код фигачать лишние строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 21:49 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
Другой вопрос конечно же что более ценно время программиста или скорость выполнения программы - скобки думаю, не сильно тут главную роль играют ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2008, 21:50 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
PtnУж не знаю как там с скобками vs точки - но вот количество строк (Антон Умников 2000й год) на скорость "влияет" - а скобки они того в код фигачать лишние строки В то время (Антон Умников 2000й год) приводился аргумент, что во время формирования объектоного кода (пи-кода) строки с точками так и обрабатываются как отдельные строки исходного кода, а строки со скобками по возможности преобразовываются в одну строку пи-кода. Трудно сказать, насколько эта оптимизация кода в действительности происходит, но звучит красиво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2008, 04:12 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
понятны - спасибо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2008, 08:02 |
|
||
|
Интересно ваше мнение...
|
|||
|---|---|---|---|
|
#18+
ser_shu PtnУж не знаю как там с скобками vs точки - но вот количество строк (Антон Умников 2000й год) на скорость "влияет" - а скобки они того в код фигачать лишние строки В то время (Антон Умников 2000й год) приводился аргумент, что во время формирования объектоного кода (пи-кода) строки с точками так и обрабатываются как отдельные строки исходного кода, а строки со скобками по возможности преобразовываются в одну строку пи-кода. Трудно сказать, насколько эта оптимизация кода в действительности происходит, но звучит красиво. По нашей MX-технологии получется так, что отдельные строки m-кода, сидящие в отдельных ячейках EXCEL, перед исполнением автоматом сшиваются в одну длиннющую m-строку, то есть динамически , вариантно, строится большая строка-программа c вложенными циклами, после чего эта строка посылается на сервер Cache/MSM для исполнения. Случайно выяснилось , что, вопреки опасениям, такая авто-сшивка заметно повысила скорость работы - например, тупое перелопачивание 100 000 записей длиной по 50-100 байт идет 5 сек против 10 сек по традиционной - многострочной - программе. Вероятно, потому, что компилируется один раз ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2008, 09:03 |
|
||
|
|
start [/forum/topic.php?fid=39&msg=35246985&tid=1558930]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
84ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 463ms |
| 0 / 0 |
