█ 01.07.2022 13:28
Цитата:
А Вы двумя-тремя ноликами не ошиблись? У меня в 1с77 в самом маленьком магазинчике база содержит более 10 000 товаров... А в средних, от 50 до 100 тысяч... И это за значительно меньший период. amadey ➤ обслуживала 4 собственных магазина и кучу сторонних, в которой 2000 наименований товаров...
█ 01.07.2022 14:47
Сейчас глянул 41 счёт за июнь 2022 года, там 7000 активных товаров ( это которые реально есть на остатках в учётной системе )
( это в одной организации )
( это в одной организации )
█ 01.07.2022 15:15
Цитата:
Разумеется, речь про обычные приложения. У тебя приложение выходит за пределы 4гб оперативки? У меня тоже нет. Сервера баз данных и т.п. это другая тема. Поэтому наши приложения будут в общем случае в 32 битах работать быстрее, чем в 64 битах, даже с учетом эмуляции, так как в 64 битах увеличивается длина передаваемых инструкций. У нас этот вопрос тоже обсуждался, вывод был такой. AndreyZh ➤ Одна мысль, но сколько в ней неоднозначных утверждений!!! Я в восторге! Попробую написать, но не буду доказывать, т.к. требует много времени... Однако эти исследования проводились в 2010-2011 годах.
1. Возможно скорость в рамках Ram, как писал выше у 32 разрядного приложения выше, но я писал о ситуации выхода из пределов памяти;
2. Приложения на [x]Harbour имеют единый исходный код, компилируются в один код для приложений любой разрядности, т.е. мне ничего не нужно "модифицировать":
3. На этапе сборки exe файла выбранным компилятором C++ происходит подключение библиотек от C++, адаптированных под соответствующую ОС и/или разрядность... В результате моё прикладное приложение сразу начинает удовлетворять технологиям, ограничениям среды компиляции C++... При обсуждениях, например убирается ограничение на размер файла 4Гб или точность расчетов.
1. Возможно скорость в рамках Ram, как писал выше у 32 разрядного приложения выше, но я писал о ситуации выхода из пределов памяти;
2. Приложения на [x]Harbour имеют единый исходный код, компилируются в один код для приложений любой разрядности, т.е. мне ничего не нужно "модифицировать":
3. На этапе сборки exe файла выбранным компилятором C++ происходит подключение библиотек от C++, адаптированных под соответствующую ОС и/или разрядность... В результате моё прикладное приложение сразу начинает удовлетворять технологиям, ограничениям среды компиляции C++... При обсуждениях, например убирается ограничение на размер файла 4Гб или точность расчетов.
Тебе ничего не нужно модифицировать, если дали готовые библиотеки c++ (про что я пытался написать), которые уже адаптированы для 64 бит, а также если у тебя в программе для адресации используются не ulong, а ulong х 2. Либо ты совсем не используешь win api и указатели при работе с бд.
█ 01.07.2022 15:20
Цитата:
Я понял. Маэстро так стебется. Сейчас все накинутся на него, что он никакой не Моцарт, а Паганини, ничего в базах данных не понимает. А у него организм так эндорфинчики выделяет. amadey ➤ А причина этого - в бездумном использовании индексов везде где не попадя. Какой смысл в индексах на документе из 10 товаров?
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.
█ 01.07.2022 16:32
Цитата:
Уже назвал эту тему "беспорядочным чатом", т.к. всё здесь свалено в кучу, т.ч. пропустил сообщение с предыдущей страницы, где указал на наличие таких потребностей: https://olegon.ru/showpost.php?p=384728&postcount=184 FinSoft ➤ Разумеется, речь про обычные приложения. У тебя приложение выходит за пределы 4гб оперативки? У меня тоже нет.
Цитата:
Ошибочное предположение даёт неверные выводы. Так же выше упоминал, что 4Gb - смешной размер для программ семейки 1ц FinSoft ➤ Поэтому наши приложения будут в общем случае в 32 битах работать быстрее, чем в 64 битах, даже с учетом эмуляции, так как в 64 битах увеличивается длина передаваемых инструкций. У нас этот вопрос тоже обсуждался, вывод был такой.
Цитата:
Нет жестких типов данных в Harbour. Приведу описание: FinSoft ➤ Тебе ничего не нужно модифицировать, если дали готовые библиотеки c++ (про что я пытался написать), которые уже адаптированы для 64 бит, а также если у тебя в программе для адресации используются не ulong, а ulong х 2. Либо ты совсем не используешь win api и указатели при работе с бд.
Цитата:
Вообще для общего развития посмотри заметку по инструменту в WiKi: , где, кстати упомянуто и моё скромное детище "УС Лэнд" Встроенные типы данных
В Harbour есть 6 скалярных типов данных: ничто Nil, строка String, дата Date, логический тип Logical, число Number, указатель Pointer, и 4 составных типа: массив Array, объект Object, блок кода CodeBlock и хеш Hash. Скалярные данные содержат единичное значение — такое как строка, число или ссылка на переменную любого другого типа. Массивы — это упорядоченные списки скалярных или составных значений (то есть элементом массива может быть в том числе и другой массив, а его элементом — другой и т. п.), индексированный по номеру, начиная с 1 (а не с 0, как в некоторых других языках). Хеш-таблицы, или ассоциативные массивы — неупорядоченные собрания значений любых типов, индексируемые по ключу, связанному с каждым значением, который может быть любого скалярного или составного типа.
В хеш-таблицах в качестве ключа для любого элемента может использоваться значение любого типа, включая другую хеш-таблицу. Хеш-таблицы и массивы могут содержать в качестве значения любого элемента значение любого типа, в том числе вложенные массивы и хеш-таблицы.
Блоки кода могут содержать ссылки на переменные процедуры, функции или метода, в котором определён блок кода. Такие блоки кода могут возвращаться в виде значения или в аргументе, передаваемом по ссылке; в этом случае блок кода «переживёт» подпрограмму, в которой он определён, и все переменные, на которые он ссылается, будут «отсоединенными (detached)» переменными.
Отсоединенные переменные сохраняют своё значение, пока существует ссылающийся на них блок кода. Эти значения будут общими для всех блоков кода, у которых есть доступ к тем же самым переменным. Если блок кода не переживает содержащую его подпрограмму и вычисляется за время жизни подпрограммы, в которой он определён, изменения в его отсоединённых переменных, вызванные его вычислением, отражаются в этой подпрограмме. Блок кода можно вычислять неограниченное количество раз с помощью функции Eval(Блок кода).
В Harbour есть 6 скалярных типов данных: ничто Nil, строка String, дата Date, логический тип Logical, число Number, указатель Pointer, и 4 составных типа: массив Array, объект Object, блок кода CodeBlock и хеш Hash. Скалярные данные содержат единичное значение — такое как строка, число или ссылка на переменную любого другого типа. Массивы — это упорядоченные списки скалярных или составных значений (то есть элементом массива может быть в том числе и другой массив, а его элементом — другой и т. п.), индексированный по номеру, начиная с 1 (а не с 0, как в некоторых других языках). Хеш-таблицы, или ассоциативные массивы — неупорядоченные собрания значений любых типов, индексируемые по ключу, связанному с каждым значением, который может быть любого скалярного или составного типа.
В хеш-таблицах в качестве ключа для любого элемента может использоваться значение любого типа, включая другую хеш-таблицу. Хеш-таблицы и массивы могут содержать в качестве значения любого элемента значение любого типа, в том числе вложенные массивы и хеш-таблицы.
Блоки кода могут содержать ссылки на переменные процедуры, функции или метода, в котором определён блок кода. Такие блоки кода могут возвращаться в виде значения или в аргументе, передаваемом по ссылке; в этом случае блок кода «переживёт» подпрограмму, в которой он определён, и все переменные, на которые он ссылается, будут «отсоединенными (detached)» переменными.
Отсоединенные переменные сохраняют своё значение, пока существует ссылающийся на них блок кода. Эти значения будут общими для всех блоков кода, у которых есть доступ к тем же самым переменным. Если блок кода не переживает содержащую его подпрограмму и вычисляется за время жизни подпрограммы, в которой он определён, изменения в его отсоединённых переменных, вызванные его вычислением, отражаются в этой подпрограмме. Блок кода можно вычислять неограниченное количество раз с помощью функции Eval(Блок кода).
█ 01.07.2022 16:40
Цитата:
Андрей, я поискал, но не нашёл на этой страничке в вики упоминания "УС Лэнд". AndreyZh ➤ где упомянуто и моё детище "УС Лэнд"
Скажи точнее, плиз, где посмотреть
█ 01.07.2022 16:48
raidex, "Тиражируемое ПО, написанное на Harbour" - раскрываете табличку и видите - в шестой строке оно.
█ 01.07.2022 17:36
Андрей, как-то не очень понятно ты пишешь. 2гб это обычно ограничение на размер файла базы данных (бывает допустимый размер и до 4гб). Если у тебя dbf, то это размер одной таблицы. Чтобы угнать систему в своп, надо забить используемыми данными всю память. Скорее всего, речь идет не о своппинге, а о повторном чтении с диска.
Если вся база помещается в оперативной памяти, то операционка ее туда кэширует при первом обращении, и затем читает из кэша. Если не помещается, то при разных обращениях считывает заново с диска. Чтение с диска будет заметно медленнее. Но надо учитывать, что в нормальных библиотеках, работающих с файлами базы данных, не все затягивается в оперативку. Если используется индекс, то там оптимизированный поиск по каждому уровню (полю). Поэтому обычно говорят о кэшировании в оперативной памяти дневных обращений к базе данных. Тут очень хорошо помогает использование ssd, который в значительной мере компенсирует это.
Когда у меня самая большая база данных стала подходить к предельным цифрам, то я переключил ее на актиан зен. Поскольку раньше его не использовал, то решил не включать режим сжатия записей. В результате база выросла в несколько раз. На каком-то этапе дневные обращения перестали помещаться к кэше актиан зен (он использует свой, кэш операционной системы не рекомендуют), скорость построения объемных отчетов стала проседать. Поставили вместо hd ssd, все закрутилось почти так же, как в случае, когда все дневные обращения помещались в кэше. Потом еще переключил работу с ресурсоемкого фифо на среднескладские цены (в этой ситуации фифо не имело смысла из-за большого процента пересортицы), все заработало стабильно быстро.
Еще надо учесть, что при использовании какого-нибудь сервера базы данных, сам сервер может быть 64 бита, а приложения, работающие с ним, 32 битными. Было бы неплохо иметь возможность работать с файловыми базами, размер таблиц которых превышает 2гб, но все же тут, наверно, более оправдано применение специализированных серверов баз данных.
Мерить скорость по базам 1с может быть интересно только 1с-никам. Там довольно специфичная работа с данными.
Если вся база помещается в оперативной памяти, то операционка ее туда кэширует при первом обращении, и затем читает из кэша. Если не помещается, то при разных обращениях считывает заново с диска. Чтение с диска будет заметно медленнее. Но надо учитывать, что в нормальных библиотеках, работающих с файлами базы данных, не все затягивается в оперативку. Если используется индекс, то там оптимизированный поиск по каждому уровню (полю). Поэтому обычно говорят о кэшировании в оперативной памяти дневных обращений к базе данных. Тут очень хорошо помогает использование ssd, который в значительной мере компенсирует это.
Когда у меня самая большая база данных стала подходить к предельным цифрам, то я переключил ее на актиан зен. Поскольку раньше его не использовал, то решил не включать режим сжатия записей. В результате база выросла в несколько раз. На каком-то этапе дневные обращения перестали помещаться к кэше актиан зен (он использует свой, кэш операционной системы не рекомендуют), скорость построения объемных отчетов стала проседать. Поставили вместо hd ssd, все закрутилось почти так же, как в случае, когда все дневные обращения помещались в кэше. Потом еще переключил работу с ресурсоемкого фифо на среднескладские цены (в этой ситуации фифо не имело смысла из-за большого процента пересортицы), все заработало стабильно быстро.
Еще надо учесть, что при использовании какого-нибудь сервера базы данных, сам сервер может быть 64 бита, а приложения, работающие с ним, 32 битными. Было бы неплохо иметь возможность работать с файловыми базами, размер таблиц которых превышает 2гб, но все же тут, наверно, более оправдано применение специализированных серверов баз данных.
Мерить скорость по базам 1с может быть интересно только 1с-никам. Там довольно специфичная работа с данными.
█ 01.07.2022 17:54
Цитата:
читая это я прям рука-лицо сделал. Амадей, продайте свою программу какой-нибудь корпорации и через год еще раз расскажете нам какая ваша база классная. К сведению. У нас у клиентов ДОКУМЕНТЫ иногда встречаются размером в 1,5 ГБ с кучей pdf вложенных. Покажите как на ваших 30 МБ это классно все будет храниться. amadey ➤ А причина этого - в бездумном использовании индексов везде где не попадя. Какой смысл в индексах на документе из 10 товаров?
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.
Но вернемся к теме форума - по ЕГАИС пока встреченный мной рекорд - это остатки в 72МБ (более 1 млн бутылок на оптовом регистре). Там ни УТМ, ни наше ПО такие файлы переварить нормально не может. И да, легенькая Derby, используемая в УТМ (сравнима с вашей БД) такие документы нормально не переваривает. А их в БД может накопиться не один и не два - остатки запрашиваются довольно часто.
█ 01.07.2022 18:44
Вячеслав... прежде, чем отвечать гляди плиз в ссылки и обоснования... и так пытаюсь писать максимально кратко...
На скрине использует памяти. 3.2Gb … это не самая большая БД
Цитата:
Влом искать "глубже", но одна из БД (совокупность таблиц и интексов) клиента у меня в "мусорке". Прога открывает её всю и реально использует объем памяти = размер_БД * 4, т.е. это реальное использование памяти инструментом, например при построении сложно отчета, где собираются данные из всех регистров. FinSoft ➤ Андрей, как-то не очень понятно ты пишешь. 2гб это обычно ограничение на размер файла базы данных (бывает допустимый размер и до 4гб). Если у тебя dbf, то это размер одной таблицы. Чтобы угнать систему в своп, надо забить используемыми данными всю память. Скорее всего, речь идет не о своппинге, а о повторном чтении с диска.
На скрине использует памяти. 3.2Gb … это не самая большая БД
Часовой пояс GMT +3, время: 06:47.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.