Дня доброго.
Есть задача собрать хеш с данных, записать его в 1С и выполнять поиск по нему.
Хеш я решил собрать MD5, проверил на 15 млн. записей, коллизий не нашел.
MD5 - это 16 байт и я их отлично засуну в УникальныйИдентификатор 1С и проиндексирую.
В виде строки это будет 32 символа, 64 байта в данных и такое хранение хеша и его индекса нам и вообще не нужно.

Новый ХешированиеДанных(MD5) возвращает хеш в виде ДвоичныхДанных, которые мне надо преобразовать в UUID.
Делаю я это так:

Функция ПреобразоватьДвоичныеДанныеВУникальныйИдентификатор(Данные) Экспорт
    Если Данные.Размер()<>16 Тогда //В уникальном идентификаторе должно быть 16 байт
        Возврат Неопределено;
    КонецЕсли;
    БуферДвоичныхДанныхХеша=ПолучитьБуферДвоичныхДанныхИзДвоичныхДанных(Данные); // 16 байт
    
    D1=БуферДвоичныхДанныхХеша.ПолучитьСрез(0,4); // 4 первых байта
    D1=D1.Перевернуть(); // hex требует bigEndian
    D2=БуферДвоичныхДанныхХеша.ПолучитьСрез(4,2); // 2 вторых байта
    D2=D2.Перевернуть();
    D3=БуферДвоичныхДанныхХеша.ПолучитьСрез(6,2); // 2 третьих байта
    D3=D3.Перевернуть();
    D4=БуферДвоичныхДанныхХеша.ПолучитьСрез(8);   // 8 байт остатка
    D40=D4.ПолучитьСрез(0,1);
    D41=D4.ПолучитьСрез(1,1);
    D42=D4.ПолучитьСрез(2,1);
    D43=D4.ПолучитьСрез(3,1);
    D44=D4.ПолучитьСрез(4,1);
    D45=D4.ПолучитьСрез(5,1);
    D46=D4.ПолучитьСрез(6,1);
    D47=D4.ПолучитьСрез(7,1);
    
    D1=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D1);
    D2=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D2);
    D3=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D3);
    D40=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D40);
    D41=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D41);
    D42=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D42);
    D43=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D43);
    D44=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D44);
    D45=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D45);
    D46=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D46);
    D47=ПолучитьHexСтрокуИзБуфераДвоичныхДанных(D47);
    ИдентификаторСтрокой=D1+"-"+D2+"-"+D3+"-"+D40+D41+"-"+D42+D43+D44+D45+D46+D47;
    Возврат Новый УникальныйИдентификатор(ИдентификаторСтрокой);    
КонецФункции

Я эту шлабуду проверил, сохранив эти ДвоичныеДанные в файл, загрузив его 16 байт в Дельфи, в TGUID и преобразуя TGUID в строку.

Именно таким образом я понял, что нужно делать:
D1=D1.Перевернуть(); // hex требует bigEndian

так как порядок байт в hex представлении не совпадал (сформированной в 1С и Дельфи).

Конечно, пофиг, у меня обратной функции не будет и она не требуется, но все же.

Вообще, нет ли каких - то вшитых ограничений на TGUID. Можно ли в него засовывать все, что хочешь.
Я прогнал 10Кзаписей и пока вроде норм.

Дальше потестю на 15 млн, но думаю, все будет ок.

(0) >ИдентификаторСтрокой=D1+"-"+D2+"-"+D3+"-"+D40+D41+"-"+D42+D43+D44+D45+D46+D47;

замени на СтрШаблон()

Зачем все это?

(3) Процитирую то, что написал на партнерке:

"В связи с активным внедрением систем маркировок и прослеживаемости товаров встает проблема адекватного хранения цифровых идентификаторов.
На данный момент, цифровые идентификаторы представлены нижней частью ASCII таблицы символов (цифры и латиница) и позволяют хранить себя в однобайтных строках.
Для цифровых идентификаторов размером 150 символов (новые алкогольные марки) это становится уже критичным.
Использование 2-хбайтных строк влечет за собой 2-х кратный рост как таблицы данных, так и таблицы индекса по этому идентификатору, а также избыточные накладные на обновление индекса и поиска по нему.
Конечно, мы можем это обойти построением хешей MD5, размером в 16 байт, которые корректно можно преобразовать в УникальныйИдентификатор и реализовать хранение средствами платформы, а значения цифровых идентификаторов хранить в хранилище значений, перегнав их в однобайтную строку, но это как то странно выглядит в целом."

У нас таблица марок уже самая большая в системе.
Ушедшие марки я хочу архивировать, исключая из индекса строковое ее представление и помещая ее в однобайтное хранилище (скорее всего без сжатия). А в индекс засовывать 16 байтных хеш для поиска.

(0) И код оптимизируй, точнее надо будет сравнить по скорости
Может проще
ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.MD5);
ХешированиеДанных.Добавить("Hello Word!");
MD5Строкой = СокрЛП(ХешированиеДанных.ХешСумма);

И далее из строки вытащить в формат для Новый УникальныйИдентификатор

(6) "MD5Строкой = СокрЛП(ХешированиеДанных.ХешСумма);"
Это недокументированная фича.

(7) Кто сказал?

(8) Base64Строка(), добавляющий переносы строк, сказал.

(8) Да, это работает, но вдруг 1С скажет - ага и выключит. Лучше я документированными методами это сделаю. По быстродействию все нормально.

(9) (10) ПолучитьСтрокуИзДвоичныхДанных ?

(4) 13млн марок весит 5.5Гб с SHA256 по приходу (переделал кстать как в других темах советовали). Можно и до 3-4 Гб уменьшить, но тогда будет долгая запись.
В основном это сигареты за 10 мес. Очистку не делал, объем считаю приемлемым, когда начнут расти таблицы буду удалять проданные марки.

(11) Нет, Егор.

(11)+ хотя это изврат

Кстати изначально хеш MD5 для поиска это изврат

(12) Ну я пока буду архивировать, если они будут заново по возвратам заходить - разархировать.

Имхо выноси наружу из 1С и не страдай хе

(15) Дадада, Егор. По сабжу что-то будет?

(17)+ sqlite или иная СУБД

(18) см (17)

про код ничего

(0) имха зачем имитировать рабоиу субд по хранению и
поиску ?  Неужели субд загнется при поиске в табличке по полю с типом варчар150?

(20) Ок.

(21) А вы не в КТ-2000 работаете :-) ?
https://kt-alkogol.ru/forum/10-----/6641-khranilishche-aktsiznykh-marok.html

(21) можно SGTIN разбить на две части так то и хранить в двух табличках

(24)+ или иной идентификатор если у него определен внутренний формат по которому можно разделить

(25)+ а делать от длинного идентификатора MD5 хэш и хранить его это легкий изврат

(16) Я планирую раз в месяц\квартал окончательно удалять записи из БД после истечения срока возврата от покупателя. Удаляемые данные скидывать в текстовый файл с архивированием.
Зачем этот мусор старый? :)

(25) (26) Это можно было бы сделать для новых марок, у которых есть значащая часть в первые 14 символов, но у нас остаются старые марки, у которых другая значащая часть. Писать 2 алгоритма это не меньший изврат.

(25) (26) Ну и переход на эту стратегию влечет большие изменения, а тут я делаю лишь надстройку и не рушу все работающее.

(27) Иногда может пригодиться для разбора ситуаций

(27) Срок возврата как то регламентирован?

(31) 3 года вроде или "срок годности"

(32)+ Учти что марки будут повторяться через ХЗ лет
Это заложено

(30) Думаю файл формировать по наименованию GTIN + Год + Месяц/Квартал. Если надо будет поднять историю, то сделаю обработку по поиску марки в этих файлах.
(31) Только законом и расширенным сроком от производителя. У нас основной объем по количеству марок сигареты и молочка, не думаю что там необходимо хранить марки после продажи в течение 1-3 мес.

я бы тоже все лишнее раньше какого-то периода вынес во внешний источник

А разве в алкомарке серия+номер не уникальны?

(36) "серия+номер" занимают много места в базе, ТС решил брать от них MD5 и хранить только его

Серия 3 знака и номер 8 . Итого 11

(38) хохо

(38) https://egais.ru/files/contentSHK.pdf

(40) и что там? влом читать

(41) 150 символов что в 1С при 2 байта на символ много в базе

(42)+ 300 байт vs 16 байт УИД/Ссылка

Ну так я же предлагал оставить только серию и номер

(44) Это на новую марку. На старую - по другому.

А эти хэши хранить где?
В новом справочнике?

А каков размер самих этих марок? Я просто не в теме.

Причины заморачиваться с хешами должны быть очень весомые. Место на дисках сейчас не дорогое.

(15) почему? долго md5 рассчитывается? есть метрики?

(48) та не просто сама идея хеша для ускорения поиска теряется тут
от дублей защита слабая что один хэш будет на разные марки
короче изврат

(49) хеш не будет один на разные марки, это же его суть

(50) опс

(50) https://ru.wikipedia.org/wiki/Коллизия_хеш-функции

(46) Отдельный РС.

Значения ШК я сначалл хотел вынести в отдельный справочник и хранить их по 10000 значений в элементе, чтобы было эффективное сжатие, а в РС - указатель на место ШК (аналог хранения в файлах), но обнаружилось, что коэффициент сжатия 1 Мб шк всего 50% (1 Мб сжимается в 500 Кб), так как криптохвосты слишком уникальны.
Лучше всего срабатывал bzip2 (скорее всего из-за преобразования Барроуза — Уилера), но на столь малый выигрыш я решил забить и хранить ШК в элементе справочника.

Эм... А стоит ли овчинка выделки? Расчет делал, сколько твои 15 млн занимают и втом и в том виде?

(52) мд5 не надежен из-за существования алгоритма поиска коллизии, а не из-за алгоритма формирования. по мощности вроде 10е-8 данные/мд5, на реальных будет типа 10е-30 и все норм если в егаис хацкеров не завезут

+ афаир там атака подменой блока, т.е. она алгоритмически не реализуема на 200 байтах

(54) 166 против 300 байт
(0) Каким методом получаешь однобайтовую строку?

(28) А чем плохо написать разные алгоритмы для разных видов марок?
1) для ЧЗ: ГТИН+СерНУМ
2) для новой алкомарки: первые 14 символов
3) для старой алкомарки: 23 символа, начиная с 9-го.

Чем не ХЭШ-функция? И никаких вероятностных коллизий. И заодно готовый КИ (CIS) без траты времени его вычисления доп. функцией

(0) Спрашивается, для чего хранить это в 1С, может все таких вынести.?

(58) Не меньше времени уйдет вычислять какой вид у тебя марки .

Нахер чота выдумывать. Хранить как есть во внешней базе. Дешево, удобно и практично. Пока Китайцы не перестали делать нам новые террабайтные диски, проблем нету.

(61) Как будто хранение во внешней базе сделано из коробки и не надо для этого тоже код писать выдумывать. А потом при надобности обратно все забирать из внешней базы.

(62) Программисты напишут. Один хрен сидят на мисте. Пускай работают.

(0) Во одной конторе, видел вынос базы по маркам в MongoDB. Подробностей не знаю реализации . Просто видел что в базе этих марок нет.

(58) Разные регистры букв для запроса СУБД одно и тоже:
00000000000001aaaaaaa
00000000000001AAAAAAA

Соответственно в регистр сведений 1С эти марки не запишутся и вывалится ошибка: "Запись с такими ключевыми полями существует!".

(0)Круто подошел, а тупо запихал во отдельную базу, на Firberd, сделал свою оболочку для обмена.

(55) Причем тут поиск коллизии когда даже без специального поиска вероятность наткнуться слишком высока
И то что ТС "проверил на 15 млн. записей, коллизий не нашел" нихрена не значит

(61) +1 за внешнее хранение

(68) Да тупо базу 1с с одним справочником и http сервисом. Это если не обучен всяким эскулайтам, фаирбёрдам и прочим питонам с сишарпами

миллион ключей это 150 мегабайт

(70) 300 же, но все равно фигня согласен.

(71) почему 300? вроде 150 байт одна марка

(72) марка да а хранение символов в строках в 1С 2 в 1

(72) А. Ну тогда если мало, то на 1с, а если много, то на любую другую субд

Вы такие интересные.
А что даст вынос во внешнюю базу?

(75) Так вроде бы место в базе хотели съэкономить

(75) Так это с ней можно работать напрямую, не средствами 1С.
причем FireBerd делает MSSQL в легкую.
да железо у меня слабое, и готовит я не умею. Ну как-то так. вот.

(76) Ну базу то нужно разместить на том же сервере. По сети мы потеряем в производительности.

(78) А у вас конвейер чтоли с бутылками?

Или алкогольный гипермаркет

(78) Какой именно производительности вы потеряете?
Думаешь запрос внутри 1С быстрее чем запрос наружу?

(79) Ну типа подождут?

(82) Типа ты протести, причем смотря как делать запросы

(82) Ту долю миллисекунды подождут

(75) Например, возможность использовать все возможности СУБД для компактного хранения.

И для эффективного поиска, вроде блум фильтров.

(85) У тебя сервер 1С один хер сервер sql вызывает
И точно такое же если прямые запросы можешь делать на тот же сервер sql
Только не через запросы 1С а напрямую

Хотя нет, немного не так я общение построил.
Егора я просто игнорить буду.

(57) получается вся затея ради экономии пары гигабайт места на диске? Ну я прям не знаю...

(89) Хохо. Бэкап базы 1С

(90)+ Мы как доки из документооборота вынесли так бэкап (который по сложным графикам и много хранится долго) стал вместо 20 гигов всего 200мб

(89) 15 млн марок занимает 14 Гб места. Это я замерял на одном из клиентов, который набрал такой объем за 10 месяцев.
Сейчас есть клиент, который заявляет 10 млн марок за месяц. Давайте посчитаем, сколько Гб места потребуется клиенту в год на хранение всего одной таблицы в базе?

(87) ком-соединения будут долго подниматься

(93) в жопу ком

(94)+ имхо ВК или http даже если списком марки а не по одной

(92) А не анализировали как часто им эти марки нужно потом из базы доставать?

(93) COM вообще надо забыть как страшный сон и не произносить в слух. )))

(96) Нет, не анализировали.
Но иногда нужно понимать, какие марки продавали клиенту, когда он заявляет пересорт, к примеру.

(98) А какие сложности итого по выносу ? .Если  у других уже есть практика выноса за пределы 1С

В 1с их точно пихать не надо. Хоть заужимайся, один хрен база распухать будет. Да и вычисление MD5 это нихрена не быстрый процесс. Не намного быстрее обращения через сеть.

(99) У всех есть какая-то практика и они ее придерживаются.

(92) так и в чём проблема? Клиенту лишь надо подкупить ХДД, которые обойдутся в разы дешевле работ по оптимизации

(92) Ну пусть диски купит. У месяц, линия розлива до 100 гигов в пике. И ниче. Купили PCI-E SSD на терабайту нормально тянет.

(102) Я это делаю в свое свободное личное время.

(104) ну тады ладн

(98) Для "иногда" как раз лучше внешняя БД. А если это единичные случаи, то можно и текстовый фай разархивировать и погрепать.

Жаль, что не анализировали. От тебя я наоборот ожидал системного подхода.

(106) Звиняйте, ананасав нема.

(98) какие марки продавали ты не узнаешь, только можно будет определить продавали ли эти конкретно марки или нет

(107) Дима, вот ты иногда упираешься как животное на букву б

(106) +1 за внешнюю БД

(108) А?

(110) Вопрос даже не стоит

(111) у тебя же кода не будет, только хэш.
А это односторонняя функция

(110) Голосовалки жаль нет.

(112) ну вот уже и твоя система начинает обрастать костылями вместо нормальных решений

Если на блокчейн перевести алкомарки, то может пить перестанут. Пока новый блок найдется, пока на его основе создадут набор акцизов и т.д.

(109) http://www.bolshoyvopros.ru/questions/699733-kakoe-zhivotnoe-nachinaetsja-na-bukvu-b.html

(100) 71К преобразований за 6 секунд. Ну в принципе, долговато, но я попробую вынести в ВК, может даст эффект.
https://prnt.sc/126uedx

(113) Будет, Анатолий.

(119) если код остается, то в чем вообще смысл тогда

(118) А если процессор начнет дымить, то можно форточку открыть

(113) Ты немного не понял.
Проблема то в том, что
Алкомарка храниться в избыточных 300 байтах с избыточным индексом по этим 300 байтам.

Я эти 300 байт заменяю на 16 байт хеша.

А этот 150 символьный код храню в отдельном реквизите как 150 байт в ДвоичныхДанных, так как у 1С нет однобайтных строк.
И при необходимости, могу сделать обратную операцию.

(121) Ахахаха.

(122) и какой выигрыш на 1 млн марок?

(122) Получается еще и * 2 данные в базе.

(124)
300 Мб данных превращаются в 16 Мб данных.
300*1.2 Мб индекса превращаются в 16*1.2 Мб индекса

Добавляется 150 Мб данных.

(126) Время на обработку всех этих манипуляций и время выноса в стороннюю БД - очень интересно где профит будет выше.

(127) Время на обработку будет ночью регламентным заданием

(117) Подразумевал те которые Муфлоны и Уриалы

(122) ты в наименование свой хеш закинуть хочешь ?
А саму марку хранить еще где, с ссылкой на этот хеш ?
ЗЫ: всё не читал

(128) А если потребуется здесь и сейчас ? нужны данные по поиску по конкретной марки Отчет движения ?

А можно копнуть в сторону переделать строку чтобы она занимала 150 байт. Выглядеть будет типа как абракадабра, но зато 150, а не 300

(131) Марка в архиве будет восстанавливаться обратной функцией.

(132) nvarchar в SQL-е занимает 2 байта на символ.

(133) Это понятно. Интересно что будет быстрее.

(134) ну и пускай. пихать в нее строку 75 символов. В базе будет 150

Нолики поудалять

(130) Сейчас у меня есть справочник Марки, код храниться в Наименовании.
Я планирую сделать отдельный РС, в котором буду хранить хеш и ссылку на справочник, в справочнике Наименование будет пусто, а в отдельном реквизите "АрхивДанныхМарки" торчать код марки.

(136) Я это сделаю через ХранилищеЗначений.

(139) Так надо же индекс делать

(140) см (138). Индекс будет в регистре на Хеш

а зачем дополнительный регистр?

(141) Да нафиг хеш. Просто строковое поле в регистре. Только ужатое до 150 байт и всё. Чтобы хеши не считать

(141) https://cs4.pikabu.ru/post_img/big/2015/05/07/6/1430989171_1871837159.jpg

(142) Если мы добавим UID в справочник - мы сразу увеличим его на 16+16*1.2 байт на элемент для всех элементов, даже не подлежащих архивации. Это же не строковый реквизит, который 0 байт, когда он пуст.

Типа было
$0070 0071 0072 0065
стало $7071 7265
КодСимвола($7071) + КодСимвола($7275)

(146) А давай ты это сделаешь и продемонстрируешь, а я посмотрю на это?

(145) те хэш ты на для всех вычисляешь? а как поиск марки будет выполняться для незахэшированных?

(144) Колеса не каноничной формы.

(146) И что ? Будет $0070 7001 0072 0065 или $0070 0701 0702 0605 Дубль ?

(149) По канону я тоже умею

Например тупо марку перевожу в несколько УИДов и храню в РС в измерениях

(151)+ Перевожу без хеширования

(147) А мне это зачем? Ты же научные изыскания проводишь. Я тебе предлагаю вариант. Может оно быстрее работать будет, а места занимать меньше.

150 символов = УИД1+УИД2+УИД3+...
Это измерения будут
А Ресурс что хошь

(148) (148) По коду, по 150 символам. Поиск нужен при загрузке входящей ТТН и при сканировании на ТСД.
При загрузке входящей ТТН с признаком Возврат буду еще искать и по хешу, при сканировании на ТСД - искать по коду, если не нашел - тогда по хешу.

(150) Ты ничо не понял

(157) понял как (137) написал

(153) Мне нет резона рассматривать этот вариант. Я просто переведу строку в однобайтную и сохраню ее через Поток в ХранилищеЗначений.

(159) что думаешь на (154)? идею понял?

Интересно почему MS SQL server не поддерживает UTF-8 вместо юникода, это же самая оптимальная кодировка для строк.

(138) АрхивДанныхМарки..это строка 150 пожатая в хранилище ?

Так то идея понятна..ищем в наименовании, если дырка, преобразуем в хешь ищем в РС.. так ?

(163) Воистену!

(162) Да. Но не пожатая. Просто 150 символов в 150 байт.
Жать коды марок - неэффективно.

можно же еще съэкономить 1 байт больше 1 символа из кода

Посмотрел у себя.. 55млн, ~22гига (данные+индекс)

(167) хранится в 1С? У меня еще в коде справочника лежит 19 символов алкокода (38 байт данных+38*1.2 байт на индекс). Его тоже под нож.

(168) да, в 1с .. база на скуле..

А так, не проще пожать, чем в уид преобразовывать ?


    ХЗ = Новый ХранилищеЗначения(НашеЗначениеКотороеНадоСжать,Новый СжатиеДанных(9));
    СтрокаBase64 = СериализаторXDTO.XMLСтрока(ХЗ);
    СжатыеДвоичныеДанные = Base64Значение(СтрокаBase64);


    СтрокаBase64 = Base64Строка(СжатыеДвоичныеДанные);
    ХЗ = СериализаторXDTO.XMLЗначение(Тип("ХранилищеЗначения"), СтрокаBase64);
    НашеЗначение = ХЗ.Получить();


©Спиз@но с нимфостарта

а зачем хранилище в строку преобразовывать?

(169) Не жмется код марки.

Даже если их собрать единный блок из 10000 марок - тогда коэффициент сжатия будет 50% и то с bzip2, который умеет предварительно сортировать данные. Мне лениво таким заморачиваться.

(171) ясна, надо потестить..
Пока не критично. У меня РС с марками пока больше весит, чем сам справочник марок, ибо индекс покрывающий много весит.
Думаю, от чего бы избавиться. Тоскливо планы опять мониторить и собирать статистику использования индексов.

(172) Да, у меня на 2 ом месте РС. Но там уже не от чего не избавиться.
Сколько времени убито на вылизывания взаимоблокировок и попадания в индексы - я его ни за что уже не трону.

(172) Ну и все списанное через несколько дней сбрасывается во 2 РС, там с индексами попроще.

(171) Для одной марки применить Арифметическое кодирование. :)

(175) Свой алфавит, вы об этом?

Мдацкое ХранилищеЗначений сериализует мои 150 байт в 233 байта при сохранении без сжатия и в 216 байт при сжатии.
Наверное надо будет делать блоки марок.

(176) я в смысле применить эту методику кодирования к 1 марке. Возможно будет эффект

(177) Нахер?
Ты можешь просто взять свои 150 символов и поделить их на нужное число УИД каждый по 36
Тупо превратить их в УникальныйИдентификатор и заюзать как измерения в РС, в ресурс пиши 1

(178) + из 50 символов ,все равно будут повторения последовательностей  символов, по этому можно их посчитать.

+(180) *150 символов

(181) Нет там повторений, иначе их сжатие по словарю нормально бы сжимали.

Могу предложить радикальное решение твоей проблемы с хэшами, MD5 и UUID — не работай на "алкоголиков", "табачников" и прочих распространителей наркоты.

(182) Давай пример 150 символов

(183) Это интересно.

(184)
233300070266990119001TKU362V3E6AH5VNFAUTTF4X7IUTSAACSQG4MRFW4UYWIWQITOCBXZWG63SPFTFPUFDTJS6QKSRYQ4I4MRKIBH34F6FQHDCOJASAGVHP3LGMUDD3TG3K62BFAQZ5QKR5OQ

(186) Криптохвост он в поиске как бы не сильно нужен. Может отбросит?

(186) Ну и как нет, есть. Видать вы не поняли выше коммент о чем я имею ввиду.

(187) Я думал об этом, но мне стало лениво морочаться со старой и новой маркой.

(188) Приведите конкретнее пример.

(189) Мне проще, я производство, у меня только новая.

(186) Уникальных - 35 , Текст  = 2307691TKUVEAH5NF4XISCQGMRWYOBZPDJLG ,
Сим    Кол
3    10
f    9
6    8
t    8
q    8
0    7

(192) + потому сюда частотные интервалы, и т.д.

+ (192) Сим, и кол. не все в сообщение вошли

(194) + это очень в сильно кратко, много чего упущено

Раз начали меряться:
у меня уже 120 млн. кодов упаковок лекарств в системе в виде справочника - это 100Гб.
Столкнувшись с кодами, отличающимися только регистром символов (руки оторвать бы архитектору в ЦРПТ, который придумал такую возможность), влепил строку 50 символов под Base64Строка(КодУпаковки). Но у меня в справочник и без того 15 реквизитов.
К концу года ожидаю 400Гб только таблицу упаковок.

(196)
"Столкнувшись с кодами, отличающимися только регистром символов (руки оторвать бы архитектору в ЦРПТ, который придумал такую возможность),"

Люто плюсую.

(196) Не хило вас прет)

Архитектору ЦРПТ, мы, конечно, поставим отдельную песню:
https://youtu.be/7GPmw7LhE3M

(196) Типовой "ШтрихкодыУпаковокТоваров"?
Мои соболезнования.

(200) Нет, у нас ничего типового нет. Своё, но всё надо.

В типовых там вообще реализацию на тестировали на скорость, десять записей на тесте они что-ли гоняют.

(147) //А давай ты это сделаешь и продемонстрируешь, а я посмотрю на это?

&НаКлиенте
Функция ВУжатую(Стр)
    Буфер = ПолучитьБуферДвоичныхДанныхИзСтроки(Стр, "windows-1251");
    Возврат ПолучитьСтрокуИзБуфераДвоичныхДанных(Буфер, "UTF-16LE");
КонецФункции

Функция ИзУжатой(Стр)
    Буфер = ПолучитьБуферДвоичныхДанныхИзСтроки(Стр, "UTF-16LE");
    Возврат ПолучитьСтрокуИзБуфераДвоичныхДанных(Буфер, "windows-1251");
КонецФункции

&НаКлиенте
Процедура Команда1(Команда)
    Ужатая = ВУжатую("0123456789");
    НеУжатая = ИзУжатой(Ужатая);
    Сообщить(НеУжатая);
    Сообщить(СтрДлина(Ужатая));
    Сообщить(СтрДлина(НеУжатая));
КонецПроцедуры



(5) "Ушедшие марки я хочу архивировать" - а ссылки на них в виде чего остаются?
Что такое "марка" сейчас? Строка? Ссылка на справочник?

У меня тоже будет задача удалять старые упаковки, но задача упирается в логическую модель:
- будут битые ссылки в документах, а чтобы удалить документ - придется делать свертку с "вводом остатков" (документ двигает регистр сведений - историю движений упаковки). А ввод остатков по сотням миллионов упаковок .... но куда деваться.

Архивировать старые упаковки смысла не вижу - всё равно они проданы. Правда, у меня есть вторая база - промежуточная между основной и ЦРПТ, там можно будет старую историю найти.

+(203)Теперь можно тупо в регистр сведений. 150 байт съэкономили. Индекс есть. Хеши вычислять не надо.

(203) Епстественно я это попробовал.
Когда сохранишь строку в БД она станет размером в 300 байт

(206) поставь размер поля 75. задолбал

и будет 150

(207) Я с вами вежливо общаюсь, но похоже, абсолютно зря. Идите ка вы лесом.

(209) Ладно не обижайся. Я ж любя.

(210) Давай ты сохранишь в примитивнейший справочник строку в 1 байт через 1С.

(211) И нахрена?

(203) Исходная строка "0123456789" - 10 байт, сжимаем - "㄰㌲㔴㜶㤸" - 10 байт,
отличное сжатие я считаю

(213) исходная строка 20 байт

(212) Чтобы понять, что решение нерабочее.

(215)  почему нерабочее то?

(214) В 1С 10 байт, а в SQL да 20, понял фишку приема.

(217) в 1с 10 - СИМВОЛОВ

(215) а (217) уже понял

почти :)

(215) так почему не работает?

(218) 10 символов из пределов ASCII =  10байт в UTF-8, в SQl согласен 10 символов = 20 байт, а закодированных 5 символов = 10 байт, смысл есть

Марки имеют ограниченный набор символов же!
Можно сжимать использую кириллицу

(221) Ты про это (223) ранее писал?

(196) >руки оторвать бы архитектору в ЦРПТ

Может, лучше архитектору платформы?

(225) На ЦРПТ зря бочку катят там вполне продумано и хорошо по сравнению с ЕГАИС

(226)+ А реализация в конфах 1С это к ЦРПТ никак не относится

(226) Да-да..завести кучку левого и продать, очень хорошо в цтрп придумали.

И пока эти дыры не прикрыты, никак

А ждать ответа годами..

не, нам такого счастья не нать

(222) можно и сильнее сжать ибо там всего 36 символов

(228) Т.е. ты жалуешься что еще не все дыры прикрыты?
Не волнуйся постепенно дойдет что воровать станет дороже чем не воровать

Продолжаем изыскания. Забил в гугл переводчик урезаную марку. Вот результат:

㌵㌳〰 㜰 ㈰ 㘶 㤹 ㄰ 啋 насмешка 唳 䄶 㕈 兆 рвота 噔 夷 рвота 㜰 ㈰ 㘶 㤹 ㄰ писк 啋 㘳 перед уходом

что то алкогольное в этом есть

И "перед уходом" тоже в тему. Ухожу с 1 мая на cdj,jlyjt бомжевание в связи с увольнением :))

(236) Меня в отпуск даже не пускают...

Китайский регистр сведений. всё работает, HADGEHOGs. Одно измерение в 75 символов

https://ibb.co/hZKmPS1

(238) Все, я вкурил.
Да, это работает.

Признаю свою ошибку перед Кирпич. Его метод позволяет сохранить строку так, как мне надо.

(237) Да нафиг щас отпуск. Ковид. Копим деньги, сидим дома

Теперь получается все достаточно легко сделать без своих blob структур

(240) Нифига ты правильный какой :) (239) вполне достаточно

Блин, хоть бери и преобразовывай все марки

Извращенцы зачем вам китайский когда можно просто строку из 150 символов разбить на уиды по 36?
последний дополнить 0

(244) Я только не понял, почему в Хранилище значений  из 150 байт получилось вдруг 230. Откуда столько лишних байтов.

(246) Сериализация.

(246) Там как строка по сути хранится в base64 вроде бы

(0) В конечном итоге один хрен придется на внешнее (относительно 1С) хранение перейти!

Вот что бы мы все делали без маркировки? А тут работы привалило! :)

(250) Нам и без маркировки есть чем заняться.

(244) Но... наименование удалять всё равно будешь и РС новый лепить ?...
Или просто наименование  на китайщину поменяешь ? :)

В принципе, замена на китайщину уже в 2 раза меньше размер.

(252) Наименования чистить. Индекс же.

(254) да, но если не чистить, а тупо китайщиной заменить, то в 2 раза пожмётся и так.
А в менеджере справочника в представлении уже подменять китайщину на нужное.. и всё красиво - на экране норм шк, в базе китайщина, и без РС

(255) Ну да, но это полумеры.

(245) а 1С даст запихнуть в УИД любую неформатную хрень?

(257) Вроде дает.

(206) поставь фиксированную длину строки - будет nchar(150), а это 150 байт

А нет, обманули )

Но 2 байта можно сэкономить )

(239) А если усовершенствовать "метод Кирпича", то можно строку сократить не до 75 символов, а до 38! ;)

(192) "Уникальных - 35 , Текст  = 2307691TKUVEAH5NF4XISCQGMRWYOBZPDJLG"
Нет, всего 23 символа, начиная с 9-го, писал об этом в (58).

(262)И как?

(264) Емкость алфавита алкомарки 36 символов (10 цифр + 26 лат. букв).
Емкость 1 байта = 255.
256 / 36 = 7,1111.
Следовательно в одном байте (символе) можно хранить 7 символов алкомарки.
Длина алкомарки = 150 символов.
Следовательно, для хранения одной марки требуется 150 / 7 = 22 байта.
в 1с8 можно хранить в виде "китайского" алфавита по "методу Кирпича" в строке длиной 2*22 символа (выше я немного ошибся, написал 38).

(265) получается что делаем хэш на 16 байт от данных на 22 байта

(196) "Столкнувшись с кодами, отличающимися только регистром символов (руки оторвать бы архитектору в ЦРПТ, который придумал такую возможность),"
А что делать, если у молочки только 5 символов в серийном? Это только 656млн марок на одну продукцию без верхнего регистра, а с ним почти 4млн.

(267) *4млрд

(266) дык написать свой https://ru.wikipedia.org/wiki/Base64
на основе символов в марках

(265) Ой, я лажу написал. Надо же не делить, а вычислять логарифм по основанию 2.
Получается для 36 символьного алфавита нужно 6 бит с избытком, значит строку в 150 символов можно хранить в 114 байтах.

(269) к (265)

(270) Не так считаешь, там просто не в байтах хранение а в битах

(267) ну да в битах: 150 симв. * 6 бит = 900 бит
Что примерно равно = 113 байтов (900 / 8)

(272)+ в смысле 36 это не 6 бит ровно а дробное и можно это дробное для следующего символа алфавита использовать

(274) Об этом тоже думал, но экономия будет не соизмерима со сложностью алгоритма.

(274) Если так рассуждать, то и до алгоритмов сжатия дойдем))

(267) В лекарствах - 13. Вопрос к тем, кто такое придумал. Зато у вас криптохвоста нет. Как жить без него будете - не представляю :)

(276) угу по Шеннону

(277) в МДЛП криптохвост есть но он только в печатном виде в обменах не участвует

(278)+ ли все же Хаффману?

(280)+ хотя правильней https://ru.wikipedia.org/wiki/Asymmetric_numeral_systems

Действительно. Если паковать в 22 байта, то хешировать смысла нет. И можно будет это засунуть в 11-символьную китайскую строку :)

Хотя стоп. Не. В 11-символьную не засунешь.

Что-то вы намутили с китайскими UTF. Там же еще номер страницы сидит плюс китайские символы до 4 байтов могут занимать.
Напрашивается в два уида кодировать. И хрен с ним с хвостиком.

Стоп. Зачем уид? А сколько в базе займет тупо 4 разрядное целое?

Не, это я гоню.

(284) разбивать на уиды я предложил еще хз когда

(287) Просто практичнее всего таки использовать байт на символ, а это дохрена уидов получается. Идея в (203) очень привлекательная, но у меня есть подозрения, что не взлетит. То есть преобразования в 75 строку туда и обратно могут происходить с потерей данных.

(263) Очень  странно судить по алфавиту марки, опираясь на один пример.

В принципе, еще достаточно практично получится пихать 3 символа в два байта. То есть упаковать в 100 байт.
Если уидами без хеширования, то это 7 уидов. Тоже как-то несподручно.

(289) То есть? Я опираюсь не на один пример, а на знания того как устроена алкомарка.

(291) Ок. Я просто подумал, что вы написали, исходя из сообщений выше.

(292) Вот регулярное выражение для проверки алкомарок всех типов (150, 68 и 40 (очень древних) символьных):
([1-9]\d{2}|\d([1-9]\d|\d[1-9])){2}([1-9]\d{7}|\d([1-9]\d{6}|\d([1-9]\d{5}|\d([1-9]\d{4}|\d([1-9]\d{3}|\d([1-9]\d{2}|\d([1-9]\d|\d[1-9])))))))(0[1-9]|1[0-2])(1[8-9]|[2-9][0-9])([1-9]\d{2}|\d([1-9]\d|\d[1-9]))[0-9A-Z]{129}|\d\d[a-zA-Z0-9]{21}\d[0-1]\d[0-3]\d{10}[a-zA-Z0-9]{31}|[0-9]{40}

Как видим разрешены только A-Z0-9 - т.е. алфавит 36 симв.

(284) могут и занимать по 4, но мы же берем только те что по 2 байта.
мы же не переводим человеческий язык

несколько гуидов - это не очень хорошо, ибо нужно рс городить для поиска

(295) РС быстрее чем справочник и очень удобно

(296)+ Точнее неудобно что идентификатора нет и в другие объекты в реквизит ссылку не засунешь
Но в задаче это не особо надо

(297) а где хранить марки привязанные к документам?
там же эти составные уиды и хранить?

(298) Дополнительное измерение ведущее в РС, там уид, этот уид в документах

300

(300) Подставляешься

(292) полученные данные о китайщине, как будешь использовать ? Всё равно, марки без наименованием с реквизитом-хранилище и в РС - китайщина как хеш индексированная ?

(302) Хеш буду брать из исходной строки.

Сейчас я прогоняю тест на 15 млн.
Марка->Китаещина->МаркаВосстановленная

И сравниваю Марка и МаркаВосстановленная

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

зачем нужен хэш тогда?

(304) Посмотрим на алфавит и скорость конвертации, может и не нужен.

можно не 7 символов пихать, а 256/64 = 4.
тогда алгоритм будет существенно проще

(306) не понял

(306) мой пост (265) неверный. Не нужно на него опираться.

(307) А ты уже протестил (203)? Оно работает корректно туда-обратно на твоей выборке (на строке в 75 символов)?

Я просто я не уверен, как ведет себя конвертация для участков кодов символов которые неопределены или зарезервированы. Не похерятся ли они при конвертации туда и обратно.

я бы создал таблицу в sql базе 1с и работал бы с ней средствами ado из 1с.

(309) я проверил на паре мультов, норм. На 55 1с-ина сваливается в недостатке памяти для выполнения запроса..

(309) На 10000 марок нормально работает

(304) Хэш может пригодиться разве что для экономии места на диске за счет уменьшения размера индекса.
(312)(313) Здорово. Кирпичу респект.
И как все-таки оптимально сжимать? Если алфавит в 36 знаков, то ничего умнее чем кодировка 3 символов в два байта мне не приходит. То есть бить на группы по 3 символа, интерпретировать их как трех-разрядное число число в 36-ричке и писать в два байта. Тогда можно будет уложиться в 50 "китайских" символов.

(314) Самое оптимальное сжатие (с точки зрения размера) это https://habr.com/ru/post/190202/

(315) Не. Речь про 1С. Простота и скорость преобразования тоже важны.

(315) И с чего ты решил что это будет оптимальное сжатие с точки зрения размера? Там номер позиции может превысить размер данных :)

(317) Номер позиции число - дальше хрен сожмешь

(314) >как все-таки оптимально сжимать?

Имхо вопрос не имеет ответа ибо у всех разное понимание оптимально.
Мое мнение тут не имеет смысла сжимать и хранить в базе 1С.

Храним в любой внешней СУБД и все.

(319) > Храним в любой внешней СУБД и все.
Ага. Пытаешься уйти от ответа. Переформулируем. Как бы ты сжимал это в любой внешней СУБД для минимизации размера базы?

(203) Проверил на первом попавшемся коде упаковки лекарств: 000000460026861000AAGRN8AGV
Восстановилось криво.
Кто-то еще может проверить?

(321) у тебя длина нечетная

(321) прилепи нолик и упаковывай. распаковывай и отлепи нолик

да и смысла нету на таких коротких кодах

Да, теперь норм.

Лучше Пробел

36 символов можно закодировать 6 битами, тоесть экономия 2 бита на символ, 25%. Нахрен надо такие радости.

(327) Смотря какие символы. Там же могут быть в разных регистрах + спецсимволы.

(328) Это алкоголь. У нас нет таких радостей.

(320) >> Храним в любой внешней СУБД и все.
>Ага. Пытаешься уйти от ответа. Переформулируем. Как бы ты сжимал это в любой внешней СУБД для минимизации размера базы?


Никак! Тупо выбрал бы правильно внешнюю БД, например которая умеет сжимать по дефолту

(330)+ Сцуко вы еще предложите свой архиватор написать со своей файловой и операционной системой ля

(327) Ну, я привел пример 33% экономии :) Да и на таких объемах "даже немножечко, чайная ложечка - это уже хорошо" (с)
В теории еще байта три можно сэкономить, но какой ценой...

(330) Вариант. Жаться оно должно хорошо...

(333) нет. я уже писал выше

(334) Что - "нет"? В СУБД же не обязательно построчно жать.

(330)+ https://db-engines.com/en/ranking/key-value+store

Тупо полные марки писал бы во внешнюю БД, с уид как ключ
В конфе 1С использовал этот ключ-уид где нуна

(335) Я тебе марок принес
https://disk.yandex.ru/d/-Bsd5qWbnRqdJw

попробуй их сжать.

(337) Не нужны мне твои марки :) Я на слово поверю. Они там что, изначально как из рандомайзера выходят?

(338) криптохвост же

(336) в этих key-value+store еще надо найти такую, которая не in memory
А то запихнешь туда 10 гигов и комп остановится нахрен

sqlite CREATE TABLE Marks (mark TEXT PRIMARY KEY) и хватит

(339) А, блин. Я просто не в курсах. Да, он там больше половины кода. Тогда извиняюсь.

(340) sqlite? как внешнее хранилище?

Или тупо в текстовых файлах хранить отсортированных. Двоичный поиск и сё такое.
Если конечно их искать редко будут

(343) кластерный индекс же

Так а какой смысл выносить его во внешнюю? Как его идентифицировать из 1С? Где плюсы, кроме минусов?

(345) в 1С оно идентифицируется по УИД

(346)+ Плюсы что база 1С не пухнет как бешеная при сохранении приемлимой скорости
Это важно для бэкапов, когда они часто и много хрантся

Внешнее хранилище легко и быстро (ну это от рук и мозгов зависит да) можно переделать без гребаных переиндексаций

(347)+ В крупных сетевиках эту внешнюю бд для марок делают онлайн одну на все филиалы/отделы/магазины

В самой базе 1С один есть смысл держать только актуальные марки для товара на остатках в данный момент
Все еще едущее или уже уехавшее/проданное нахрен во внешнюю

Убедил. Что-то я с гуидом сразу не допер.

Может, в самом деле в текстовые файлики складывать.
По датам генерации гуидов. По часу на файлик, скажем. Текущий час - в регистре сведений. Файлики - только на чтение.

В общем, оперативный буфер - в РС, из которого выгружаться в файлики.

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

(353) dbf во всех платформах 1С есть

(354)+ Если очень очень хочется "в базе" то засунь эту dbf в хранилище

Не. Не хочу dbf. Мне файлики нравятся. Я бы на них сделал.
Сделать папочки на день / месяц / год. Надо достать по гуиду - сразу генерится полный путь к нужному файлику. А они там уже по порядку разложены. Можно хоть тем же двоичным поиском строчку находить.
Управлять удобно. Перенести старый период на бэкап-сервер в архиве - раз плюнуть. Красота.

(356) не тупи файлики тормоза по сравнению с dbf
на dbf можно из 1С cdx сделать и быстро-быстро будет

(357)+ если один файлик dbf большой то можно их много завести, размер в гиг-два нормально

(357) Что-то мне подсказывает, что производительность достаточная будет. Хотя я без понятия в ентих алкомарках и чего с ними вытворяют. Может и ошибаюсь.

Главное, что производительность будет линейная. Если уж взлетит, то в пути не упадет.

Хотя... Можно же точно также завести по dbf на каждый час :)
Ну, можно. Не придется свой поиск в файле рисовать.

Хотя места будет больше занимать. А оно же нам важно типа. Может, лучше текст? :)

Просто у нас естественным образом "кластерный индекс" получится. Генерить по нему cdx - избыточно.

Да в sqlite загнать и всё. Там тебе и кластерный индекс и всё шо хош.

(364) не поплохеет база в скульлайте от 50-100 мультов марки ?

мне лень тестить, были бы клюшки, попробовал бы.

Восстановил 15 млн марок.
3 ошибочные
на конце вместо
150 символа комбинация
эя

сейчас буду разбираться

(367) служебные символы попало и обнулило

Все, вкурил.
Пустой алкокод у них.

Я архивирую как

Алкокод;КодМарки

19символов алкокода+1 символ разделителя + 150 символов =170 символов - четное число.

0символов алкокода+1 символ разделителя + 150 символов =151 символов - нечетное число.

Добавлю проверку на четность при архивации

Кто в ЕГАИС советую заранее готовиться к тому что все старые марки и алкокоды к черту
И заставят перемаркировать новыми от ЧЗ

(371)+ Остатки понятно перемаркировать, все проданное нафик
Если старые запасы возвращается то перемаркировка

(371) Но это вряд ли раньше чем https://xn--80ajghhoc2aj1c8b.xn--p1ai/business/projects/beer/about-experiment/
Выйдет в продакшен

(371) Откуда инфа?

(365) Так любой субд поплохеет. Ну сделай 20 баз. По 5 гигов на базу нормально будет искать.

(374) инфа с пива (373)

"Останется только один" ибо кто крепким торгует тот и пивом тоже
А юзать две разные "маркировки" дико неудобно

(376) Про пиво понятно.
Я про "Кто в ЕГАИС советую заранее готовиться к тому что все старые марки и алкокоды к черту
И заставят перемаркировать новыми от ЧЗ".

Старые марки на крепком алкоголе - почему заставят его перемаркировать?

А кстати в чем отличие акцизных марок (АМ) и федеральных специальных марок (ФСМ)

(377) а нафига ЧЗ в лице ЦРПТ заморачиваться с этими кривыми старыми марками?

(379)+ На все экспериментальные так же забивали и заставляли перемаркировать или разрешали без них до окончания срока годности
А у спиртного срок годности тю

(378) АМ - на импорт, ФСМ - отечественное, но с 2021 теперь все - ФСМ.

(373) зачет ага, а в Татарстане уже идет пилот по маркировке пива обычными ФСМ.. как на крепкий алкоголь один в один.
Эти клоуны в правительстве всё пирожок не поделят.

(382) есть такое

(382) Игры чиновников - в Татарстане это просто заградительная мера, чтобы не пустить пиво из других регионов. На всю страну не будет эксперимент Татарстана распространен.

6 Гб данных и
8 Гб индекса
превратились в
3,3 Гб данных и
1,3 Гб индекса

(385) неплохо.. это с РС ?

(386) нет, это справочник Марок

(387) ну.. без наименования ? или наименование - китайщина ?

(388) Алкокод+Наименование - в китай, в 170 байтную строку.

Отдельный РС с хешами еще не строил

(389) я в марках храню не алкокод, а ссылку на справочник алкогольного классификатора. Но, промониторив запросы, нигде это не использую. Вот и думаю, а оно мне вообще надо ? ))) Ну разве что, открыл справочник марки и видишь, че за номенклатура сразу. Хотя, марку, врят ли кто смотрит так.

Подумываю, прибить сей реквизит.

(390) Полезно иногда ткнуть быстрый отбор в динсписке, но это просто изза лени. У нас гдето в ТСД используется вроде.

Кстати ТС правильно решил сжимать
Гребаные майнеры, гребаная чиа, hdd и ssd самые большие пропали, а средние и мелкие ценник скакнул

(393) Ага. Именно под эту новость купил себе в понедельник Sams 980 на 1Тб.

(394) 1Tb ssd еще можно найти но уже убогие бренды/марки
ssd на 2Tb и более уже хрен найдешь
как и hdd >6Tb пропали
благо внешние hdd пока есть на 4-5Tb

Объясните для тупых (для меня), почему китайская раскладка 1 символ занимает 1 байт в SQL. Я прикладник, хотелось бы углубиться в дебри. Суть обсуждения потерял на 3 странице. Можно просто ссылками на матчасть (вики) закидать, там сам буду разгребать...

Какие байты?
Каждый символ кода марки имеет ограниченное число вариантов.
Получается система не по основанию 2,но все равно мы можем последовательность символов перевести в число,а уже число потом перевести в набор байтов (изначально битов).
И SQL умеет хранить символы в отличных от двухбайтовых кодировках,просто,это 1с не умеет.
Хотя,квалификаторы двоичных данных - это как раз для этого.

Кстати,в sms на латинице 160 символов кладутся в 140 байт и никто не считает,что это плохо.

(397) при конвертации из 36 в 256 получаем экономию 30%
Log_256 36

(396) Всё волшебство в (146)
Китайские буквы получаются случайно

"Ветерок раскачивает чувств качель
И такая горечь.
А любовь моя - печаль-виалончель
И на ней хреначит мертвый Ростропович."

Я в расстроенных чувствах, короче.

1С вычисляет хеш для 100000 150 символов за 8,6 секунд.
Дельфи делает это за 250 мсек.

Буду переносить в ВК, наверное.

(401) Потеряешь на передаче в ВК
Выноси уже наружу и хранение

846 мс с использованием ВК.

Обмен через кусок текста в виде строковой переменной в 100000 строк, разделенного переносами строк

250 мсек - MD5
164 мсек - MD5 в TGUID
26  мсек - разборка входящего текста и сборка исходящего текста и передача в ВК/из ВК

406 мсек - сборка в 1С массива в единый текст и разбор результата в массив и преобразование в УникальныйИдентификатор

(401) попробуй тот же самый хэш вычислять,не копируя строки,т.к.тормоза будут как раз на копировании строк.
Я когда md5 на другие языки переписывал (например,на vbscript), как раз с копированием строк боролся,т.к.это самые медленные операции.

(403) Пакуйте хеши в 16 символьный китайкод и будет вам в 1с миллион за 8 сек

Функция MD5КитайКод(Стр)
    Хеш = Новый ХешированиеДанных(ХешФункция.MD5);
    Хеш.Добавить(Стр);
    Возврат ПолучитьСтрокуИзДвоичныхДанных(Хеш.ХешСумма, "UTF-16LE");
КонецФункции


ой. 8 символьный даже

(405) гениально!

(407) А чо. Те же 16 байт, только без лишних движений по склеиванию строк для формирования GUID

(408) нет, я наоборот респектую.

(408) надо еще понять что будет с нулевым символом

(410) А что с ним?

(411) его наличие обычно трактуется как завершение строки

(412) Ну да. Два нуля подряд должно быть. А чо попадалось такое?

(412) А ты попробуй. Сделай какой нибудь FFFF0000AAAA1111

Всё нормально.

    Данные = ПолучитьДвоичныеДанныеИзHexСтроки("0000222200003333");
    Стр = ПолучитьСтрокуИзДвоичныхДанных(Данные, "UTF-16LE");
    Сообщить(Стр);
    Данные = ПолучитьДвоичныеДанныеИзСтроки(Стр, "UTF-16LE");
    Стр = ПолучитьHexСтрокуИзДвоичныхДанных(Данные);
    Сообщить(Стр);


Только как оно в БД будет не проверял. Может там сюрпрайз от 1с какой нибудь

Но вряд ли

Всё работает

    Данные = ПолучитьДвоичныеДанныеИзHexСтроки("0000222200003333");
    Стр = ПолучитьСтрокуИзДвоичныхДанных(Данные, "UTF-16LE");
    Эл = Справочники.Справочник1.СоздатьЭлемент();
    Эл.Наименование = Стр;
    Эл.Записать();
    Ссылка = Справочники.Справочник1.НайтиПоНаименованию(Стр,Истина);
    Если Ссылка <> Справочники.Справочник1.ПустаяСсылка() Тогда
        Данные = ПолучитьДвоичныеДанныеИзСтроки(Ссылка.Наименование, "UTF-16LE");
        Стр = ПолучитьHexСтрокуИзДвоичныхДанных(Данные);
        Сообщить(Стр);
    Иначе
        Сообщить("Не нашел");
    КонецЕсли;
        


А не. Глючит когда пытаешься справочник посмотреть. Недопустимые символы говорит

И если символы 00 в конце, то дальше не читает. Но это можно победить принудительным добавлением двух нулей справа

Хотя нет. С нулями в конце облом будет тоже

Разве что добавлять FFFF в конце. Но это уже не красиво

(419) Ну мы это поле выводить не будем и всё

Да и без китайкода в виде HEX строки тоже вполне приемлимо. 32 байта.

Или там 64 получается :))
Мля. Лучше уж в идентификаторах тогда.

Надеюсь вы понимаете что https://i2.paste.pics/6ef1f3ce66bd4cccfb41c2e92a0cb8ae.png

Да и с идентификаторами нормально работает. Миллион идентификаторов из хешей за 15 сек

Функция MD5Идентификатор(Стр)
    Хеш = Новый ХешированиеДанных(ХешФункция.MD5);
    Хеш.Добавить(Стр);
    Д = ПолучитьHexСтрокуИзДвоичныхДанных(Хеш.ХешСумма);
    Д = СтрШаблон("%1-%2-%3-%4-%5", Сред(Д,1,8), Сред(Д,9,4), Сред(Д,13,4), Сред(Д,17,4), Сред(Д,21,12));
    Возврат Новый УникальныйИдентификатор(Д);
КонецФункции


Про производительность можно даже не задумываться, у вас что там каждый день по миллиону марок уходит, если нет, то на что разница в 10 сек раз в день может повлиять.

(396) > Объясните для тупых (для меня), почему китайская раскладка 1 символ занимает 1 байт в SQL
Суть проблемы - нужно эффективно хранить двоичные данные и искать по ним.
Но. В 1С нет индексируемых типов для двоичных данных кроме уникального идентификатора.
Если писать символьное представление двоичных данных, то размер удваивается, так как в mssql юникодные символы занимают минимум 2 байта (для упрощения обработки UTF-8 там не используется).
Поэтому идея была в том, чтобы писать в строку не символьное представление двоичных данных, а непосредственно сами двоичные данные.
Берется по два байта двоичных данных, а в строку пишется тот символ, кодом которых эти два байта двоичных данных выступают. При этом часто (но не всегда) получаются символы с иероглифических кодовых страниц (так как их там дохрена).

Меня этот подход по-прежнему смущает. Что в очень редких случаях, когда получится код суррогатной пары или какой-то зарезервированной области, то могут быть проблемы. Но тесты на реальных данных вроде показывают что такой проблемы нет. Но осадочек все равно висит :)

(430) Так проверь и спи спокойно. Запиши и прочитай в справочник или в регистр сведений китайкод всех вариантов от '00' до 'ZZ' (в марках вроде кроме латинских буков и цифр ничего не используется)

код 'ZZ' 23130
23130 символов перебрать

(431) Согласен. Примерно так бы я и сделал.

А если брать только буквы и цифры, то там вабще 36*36 и всё читабельное (китай галимый в основном)


    Буки = "0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z";
    Массив = СтрРазделить(Буки," ");
    КитайМассив = Новый Массив;
    Для а1 = 0 по Массив.ВГраница() Цикл
        Для а2 = 0 по Массив.ВГраница() Цикл
            Буфер = ПолучитьБуферДвоичныхДанныхИзСтроки(Массив[а2]+Массив[а1],"US-ASCII");
            КитайМассив.Добавить(ПолучитьСтрокуИзБуфераДвоичныхДанных(Буфер,"UTF-16LE"));
        КонецЦикла;
    КонецЦикла;
    Сообщить(КитайМассив[0]);


Глянь в отладчике КитайМассив. Всё читабельное, красивое и китай-тамильское