Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Работаю с Таблицей (уже не называю База Данных).
Копирую данные в оперативку. Количество столбцов более 10 и это принципиально.

Еcть значение aaa(1.1) и aaa(1.10). Если задать 1.1, а затем задать 1.10 и считать данные из 1.1, то Каше выдаст нам данные из памяти со значением 1.10

Пример кода и результатов ниже.
BRENT2016>Set aaa(1.1)="aaa001"
 
BRENT2016>Set aaa(1.2)=2
 
BRENT2016>Set aaa(1.10)="No"
 
BRENT2016>Set aaa(1.20)="No"
 
BRENT2016>w aaa(1.1)
No
BRENT2016>w aaa(1.2)
No


К сообщению приложен файл. Размер - 29Kb
18 авг 17, 07:48    [20732964]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Если же сделать по другому, то результаты получаются нормальные/адекватные
Назначив не 1.1, а 1.001 и не 1.2, а 1.002

BRENT2016>set aaa(1.001)="aaa1"
 
BRENT2016>Set aaa(1.002)="Также есть"
 
BRENT2016>Set aaa(1.1)="No111"
 
BRENT2016>Set aaa(1.2)="No222"
 
BRENT2016>w aaa(1.1)
No111
BRENT2016>w aaa(1.001)
aaa1




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

К сообщению приложен файл. Размер - 34Kb
18 авг 17, 07:51    [20732966]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Да и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
18 авг 17, 07:55    [20732972]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
Еcть значение aaa(1.1) и aaa(1.10). Если задать 1.1, а затем задать 1.10 и считать данные из 1.1, то Каше выдаст нам данные из памяти со значением 1.10

Пример кода и результатов ниже.
BRENT2016>Set aaa(1.1)="aaa001"
 
BRENT2016>Set aaa(1.2)=2
 
BRENT2016>Set aaa(1.10)="No"
 
BRENT2016>Set aaa(1.20)="No"
 
BRENT2016>w aaa(1.1)
No
BRENT2016>w aaa(1.2)
No

Так и должно быть.
Ибо
TMP>w 1.1000                                                                   
1.1    
18 авг 17, 08:21    [20733016]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
Да и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")

Тут кагбэ нужно правильно "давать".

s aaa("1.Data")=""
s aaa(1_".Data")=""
18 авг 17, 08:23    [20733022]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2357
О-О-О,

Ваша "проблема" заключается в том, что вы значения пишете ч числовом представлении. И вы должны знать, что 1.1 и 1.10 это одно и то же число. И поэтому предыдущее значение терялось. А вот если бы вы взяли значение в кавычки, то оно бы стало текстом, и тогда было бы уже все равно.
USER>set a(1.1)=""

USER>set a(1.10)=""

USER>set a(1.100)=""

USER>set a("1.100")=""

USER>set a("1.10")=""

USER>zw a
a(1.1)=""
a("1.10")=""
a("1.100")=""

привести числовое значение к текстовому можно просто прибавив его с пустой строке, но нужно понимать ""_1.20 даст "1.2" а не "1.20"


О-О-О
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")

А это вообще как вы себе представляете?
почему не делать так как все?
aaa("1.Data")
18 авг 17, 08:24    [20733028]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
Вопрос. С чем это может быть связано и почему происходит именно так.

В первом варианте (1.20) Каше "не хранит" "концевые" нули, т.к. они никому не нужны. И я х/з какие ЯП вообще такое хранят, всегда "концевые" нули "исчезали".

По второму вопросу...
Что вообще такое
1.Data

или
1."Data"

т.е. как ты собирался интерпретировать этот синтаксис?
18 авг 17, 08:27    [20733032]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
С последним вопросом ответ нашулся.

Нужно было просто делать

Set aaa(1,"Data")=65000


Просто нужна была ЗАПЯТАЯ, а не ТОЧКА!
18 авг 17, 09:04    [20733139]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
С последним вопросом ответ нашулся.

Алилуя, брат! (с)
18 авг 17, 09:05    [20733146]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Немного статистики. Может кому пригодится для оптимизации.
Имеется таблица на 395000 строк. В таблице 154 столбца.

Если данные копировать в оперативку как
EndID - это последняя запись в таблице (394000)

For i=1:1:EndID
{
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
      // Где BDAnaliz Это БД откуда будут копироваться данные
   Set aaa(i)=aaaNew
}

c

Вариант №2
For i=1:1:EndID
{
   Set Nr=0
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
      // Где BDAnaliz Это БД откуда будут копироваться данные
   For em="Data","Vrema",    и т.д . (все 154 столбца)
   {
       Set Nr=Nr+1
       Set zma1="aaa("_i_"."_Nr_")=aaaNew."_em,@zma1
    }
}

Такой вариант занимает ВСЕГО 114 секунд НО остаётся ВСЕГО 2.027 Гб из 9.863 Gb выделенных. Самый быстрый вариант, но самый затратный по оперативке. Вариант получается нечитабельным, т.к. нужно держать в памяти что означает номер с реальными полем из таблицы.

Вариант №3
18 авг 17, 09:23    [20733207]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Вариант №3
For i=1:1:EndID
{
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
   For em="Data","Vrema",    и т.д . (все 154 столбца)
   {
       Set zma1="aaa("_i_"."_""""_em_""""_")=aaaNew."_em,@zma1
    }
}

Такой вариант занимает 144.40 секунды и остаётся 4.028 Гб из 9.863 Gb выделенных. Средний вариант, как по быстроте так и по занимаемой Оперативке. Зато полностью читабелен, т.к. имена данных аналогичные именам данных из таблицы.
Время с удалением данных из оперативки составило 150.39 сек.


БОЛЬШАЯ ПРОБЛЕМА ВАРИАНТА №1 ЭТО УДАЛЕНИЕ ФАЙЛА ИЗ ОПЕРАТИВКИ.
Расчет/копирование занял 233.17 секунды (вот прямо сейчас), а с удалением данных из оперативки занял уже 356.48 сек!!! То есть очень долгий по исполнению (по полному циклу исполнения кода).

Таких проблем с вариантом №2 и вариантом №3 нет.
18 авг 17, 09:39    [20733246]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Вариант №1
For i=1:1:EndID
{
Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
// Где BDAnaliz Это БД откуда будут копироваться данные
Set aaa(i)=aaaNew
}

Время исполнения составило 233.17 сек. Доступно 7.324 Гб из 9.863 Гб. Время с удалением данных из оперативки (для дальнейшего выполнения кода уже составило) 356.48 сек. Но этот вариант читабелен, т.к позволяет напрямую обращяться к данным в формате
aaa(1).Data
И данные представлены в такой же структуре, что и таблица. То есть aaa(1).Data
aaa (345).Vrema все также как и в обычной таблице на жестком диске.

Очень читабельная и удобна для работы, но жутко долго загружается и столько же удаляется из оперативки!
.
18 авг 17, 09:46    [20733260]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Пардон, в варианте №3 закрылась ошибка
вместо
Set zma1="aaa("_i_"."_""""_em_""""_")=aaaNew."_em,@zma1


нужно писать
Set zma1="aaa("_i_","_""""_em_""""_")=aaaNew."_em,@zma1


то есть не точка, а запятая!
18 авг 17, 09:50    [20733267]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
А это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?
18 авг 17, 09:53    [20733281]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,

Для кого то да.

Это комбинаторика, перебор вариантов.
Если это делать с SSD диска, то уходит около 60-75 минут.
Если этот же код делать с данными, скопированными в оперативку, то уходит около 10 минут.
18 авг 17, 09:59    [20733295]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
А меня всегда настораживали таблицы, где
О-О-О
В таблице 154 столбца.


И прям все 154 параметра заполнены у каждой строки?
18 авг 17, 09:59    [20733297]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
Это комбинаторика, перебор вариантов.

Не стоит забывать, что Каше это первым делом NoSQL и некоторые энергоемкие задачи удобнее решать именно в этом направлении, а не табличном. ;)

Про саму задачку ты ведь нам не рассказал...
18 авг 17, 10:02    [20733300]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
да, и все 154 параметра заполнены в каждой строке (реально заполнены)!.
18 авг 17, 10:03    [20733306]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Наше дело поделиться, кому то может и пригодится.
Я сижу на Каше, потому что нет задач, которые нельзя на нём сделать да и скорость его в моём понимании впечатляет.

Да и поздно уже на что то другое переходить.
18 авг 17, 10:05    [20733317]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О
да, и все 154 параметра заполнены в каждой строке (реально заполнены)!.

Все равно остается подозрение, что ты свернул не туда...
Но без знания проблемы ничего больше не скажешь. Ну не должны данные так перелопачиваться. Тут что-то не так.
18 авг 17, 10:05    [20733319]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12827
О-О-О, наша практика работы с ЦОДом показала, что на мощных серверах хорошим подспорьем является "многоджобная" технология обработки данных (это наш термин).

Т.е. если разбить "линейную" обработку данных на "куски" и все эти куски обработать отдельным, дочерним процессом, то время обработки практически "делится" на количество этих дочерних джобов. ;)

А вот по каким критериям делать те "куски", это уже решается индивидуально по каждой задаче/проблеме...
18 авг 17, 10:10    [20733334]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
Тогда попробуйте, как подсказал krvsa, использовать глобалы напрямую (минуя объектный доступ и SQL). Просто перед именем пишете ^ и все. Например:
set ^tbx( 1, "Vrem" ) = 1547.
Первый индекс от 1 до 395000, а второй - хоть текстовый по имени колонки, хоть числовой (если время, допустим, всегда считать полем № 2, то вместо "Vrem" пишем - 2). А вообще-то, krvsa прав - странная обработка данных. Но без озвученных условий Вам трудно помочь.
18 авг 17, 10:14    [20733340]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,
Я просто поделился. Помощи не просил.
Что касается много потоковости - наверное так будет быстрее, но мне удобнее так. Просто никогда не знаешь, какие данные потребуются. К тому же они служат ТОЛЬКО ДЛЯ АНАЛИЗА данных по истории (выработка стратегии). Сами торги не идут с таким перелопачиванием данных. Там все проще и быстрее.
18 авг 17, 10:37    [20733406]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше
О-О-О,
Тогда попробуйте, как подсказал krvsa, использовать глобалы напрямую (минуя объектный доступ и SQL). Просто перед именем пишете ^ и все. Например:
set ^tbx( 1, "Vrem" ) = 1547.
Первый индекс от 1 до 395000, а второй - хоть текстовый по имени колонки, хоть числовой (если время, допустим, всегда считать полем № 2, то вместо "Vrem" пишем - 2). А вообще-то, krvsa прав - странная обработка данных. Но без озвученных условий Вам трудно помочь.


Вот как раз таким способом анализ и будет длится 60-75 минут.
18 авг 17, 10:38    [20733408]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2357
О-О-О
Я просто поделился. Помощи не просил.
Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.
18 авг 17, 10:49    [20733438]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Caché Ответить