Вход | Регистрация
    1  2  3  4  5   

Прошу проверить код

Прошу проверить код
Я
   H A D G E H O G s
 
27.04.21 - 21:00
Дня доброго.
Есть задача собрать хеш с данных, записать его в 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;
    Возврат Новый УникальныйИдентификатор(ИдентификаторСтрокой);    
КонецФункции
   fisher
 
301 - 29.04.21 - 11:53
(300) Подставляешься
   Ёпрст
 
302 - 29.04.21 - 12:35
(292) полученные данные о китайщине, как будешь использовать ? Всё равно, марки без наименованием с реквизитом-хранилище и в РС - китайщина как хеш индексированная ?
   H A D G E H O G s
 
303 - 29.04.21 - 12:48
(302) Хеш буду брать из исходной строки.

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

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

Потом из этих 15 млн составлю алфавит и сделаю свой код, который сохраню в китаещину. Алфавит буду делать, если производительность будет норм.
   Вафель
 
304 - 29.04.21 - 12:49
зачем нужен хэш тогда?
   H A D G E H O G s
 
305 - 29.04.21 - 12:51
(304) Посмотрим на алфавит и скорость конвертации, может и не нужен.
   Вафель
 
306 - 29.04.21 - 12:55
можно не 7 символов пихать, а 256/64 = 4.
тогда алгоритм будет существенно проще
   H A D G E H O G s
 
307 - 29.04.21 - 13:12
(306) не понял
   victuan1
 
308 - 29.04.21 - 13:36
(306) мой пост (265) неверный. Не нужно на него опираться.
   fisher
 
309 - 29.04.21 - 13:53
(307) А ты уже протестил (203)? Оно работает корректно туда-обратно на твоей выборке (на строке в 75 символов)?
   fisher
 
310 - 29.04.21 - 13:57
Я просто я не уверен, как ведет себя конвертация для участков кодов символов которые неопределены или зарезервированы. Не похерятся ли они при конвертации туда и обратно.
   Ivan_495
 
311 - 29.04.21 - 14:07
я бы создал таблицу в sql базе 1с и работал бы с ней средствами ado из 1с.
   Ёпрст
 
312 - 29.04.21 - 14:11
(309) я проверил на паре мультов, норм. На 55 1с-ина сваливается в недостатке памяти для выполнения запроса..
   H A D G E H O G s
 
313 - 29.04.21 - 14:15
(309) На 10000 марок нормально работает
   fisher
 
314 - 29.04.21 - 14:50
(304) Хэш может пригодиться разве что для экономии места на диске за счет уменьшения размера индекса.
(312)(313) Здорово. Кирпичу респект.
И как все-таки оптимально сжимать? Если алфавит в 36 знаков, то ничего умнее чем кодировка 3 символов в два байта мне не приходит. То есть бить на группы по 3 символа, интерпретировать их как трех-разрядное число число в 36-ричке и писать в два байта. Тогда можно будет уложиться в 50 "китайских" символов.
   Garykom
 
315 - 29.04.21 - 14:52
(314) Самое оптимальное сжатие (с точки зрения размера) это https://habr.com/ru/post/190202/
   fisher
 
316 - 29.04.21 - 14:54
(315) Не. Речь про 1С. Простота и скорость преобразования тоже важны.
   fisher
 
317 - 29.04.21 - 15:00
(315) И с чего ты решил что это будет оптимальное сжатие с точки зрения размера? Там номер позиции может превысить размер данных :)
   Garykom
 
318 - 29.04.21 - 15:05
(317) Номер позиции число - дальше хрен сожмешь
   Garykom
 
319 - 29.04.21 - 15:07
(314) >как все-таки оптимально сжимать?

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

Храним в любой внешней СУБД и все.
   fisher
 
320 - 29.04.21 - 15:09
(319) > Храним в любой внешней СУБД и все.
Ага. Пытаешься уйти от ответа. Переформулируем. Как бы ты сжимал это в любой внешней СУБД для минимизации размера базы?
   ptiz
 
321 - 29.04.21 - 15:51
(203) Проверил на первом попавшемся коде упаковки лекарств: 000000460026861000AAGRN8AGV
Восстановилось криво.
Кто-то еще может проверить?
   Вафель
 
322 - 29.04.21 - 15:52
(321) у тебя длина нечетная
   Кирпич
 
323 - 29.04.21 - 15:54
(321) прилепи нолик и упаковывай. распаковывай и отлепи нолик
   Кирпич
 
324 - 29.04.21 - 15:55
да и смысла нету на таких коротких кодах
   ptiz
 
325 - 29.04.21 - 15:56
Да, теперь норм.
   H A D G E H O G s
 
326 - 29.04.21 - 15:57
Лучше Пробел
   H A D G E H O G s
 
327 - 29.04.21 - 15:58
36 символов можно закодировать 6 битами, тоесть экономия 2 бита на символ, 25%. Нахрен надо такие радости.
   ptiz
 
328 - 29.04.21 - 16:05
(327) Смотря какие символы. Там же могут быть в разных регистрах + спецсимволы.
   H A D G E H O G s
 
329 - 29.04.21 - 16:07
(328) Это алкоголь. У нас нет таких радостей.
   Garykom
 
330 - 29.04.21 - 16:18
(320) >> Храним в любой внешней СУБД и все.
>Ага. Пытаешься уйти от ответа. Переформулируем. Как бы ты сжимал это в любой внешней СУБД для минимизации размера базы?


Никак! Тупо выбрал бы правильно внешнюю БД, например которая умеет сжимать по дефолту
 
 
   Garykom
 
331 - 29.04.21 - 16:19
(330)+ Сцуко вы еще предложите свой архиватор написать со своей файловой и операционной системой ля
   fisher
 
332 - 29.04.21 - 16:20
(327) Ну, я привел пример 33% экономии :) Да и на таких объемах "даже немножечко, чайная ложечка - это уже хорошо" (с)
В теории еще байта три можно сэкономить, но какой ценой...
   fisher
 
333 - 29.04.21 - 16:23
(330) Вариант. Жаться оно должно хорошо...
   H A D G E H O G s
 
334 - 29.04.21 - 16:24
(333) нет. я уже писал выше
   fisher
 
335 - 29.04.21 - 16:29
(334) Что - "нет"? В СУБД же не обязательно построчно жать.
   Garykom
 
336 - 29.04.21 - 16:34
(330)+ https://db-engines.com/en/ranking/key-value+store

Тупо полные марки писал бы во внешнюю БД, с уид как ключ
В конфе 1С использовал этот ключ-уид где нуна
   H A D G E H O G s
 
337 - 29.04.21 - 16:45
(335) Я тебе марок принес
https://disk.yandex.ru/d/-Bsd5qWbnRqdJw

попробуй их сжать.
   fisher
 
338 - 29.04.21 - 16:47
(337) Не нужны мне твои марки :) Я на слово поверю. Они там что, изначально как из рандомайзера выходят?
   Вафель
 
339 - 29.04.21 - 16:48
(338) криптохвост же
   Кирпич
 
340 - 29.04.21 - 16:50
(336) в этих key-value+store еще надо найти такую, которая не in memory
А то запихнешь туда 10 гигов и комп остановится нахрен

sqlite CREATE TABLE Marks (mark TEXT PRIMARY KEY) и хватит
   fisher
 
341 - 29.04.21 - 16:51
(339) А, блин. Я просто не в курсах. Да, он там больше половины кода. Тогда извиняюсь.
   Вафель
 
342 - 29.04.21 - 16:51
(340) sqlite? как внешнее хранилище?
   Кирпич
 
343 - 29.04.21 - 16:54
Или тупо в текстовых файлах хранить отсортированных. Двоичный поиск и сё такое.
Если конечно их искать редко будут
   Вафель
 
344 - 29.04.21 - 16:54
(343) кластерный индекс же
   fisher
 
345 - 29.04.21 - 17:05
Так а какой смысл выносить его во внешнюю? Как его идентифицировать из 1С? Где плюсы, кроме минусов?
   Garykom
 
346 - 29.04.21 - 17:07
(345) в 1С оно идентифицируется по УИД
   Garykom
 
347 - 29.04.21 - 17:08
(346)+ Плюсы что база 1С не пухнет как бешеная при сохранении приемлимой скорости
Это важно для бэкапов, когда они часто и много хрантся

Внешнее хранилище легко и быстро (ну это от рук и мозгов зависит да) можно переделать без гребаных переиндексаций
   Garykom
 
348 - 29.04.21 - 17:09
(347)+ В крупных сетевиках эту внешнюю бд для марок делают онлайн одну на все филиалы/отделы/магазины
   Garykom
 
349 - 29.04.21 - 17:10
В самой базе 1С один есть смысл держать только актуальные марки для товара на остатках в данный момент
Все еще едущее или уже уехавшее/проданное нахрен во внешнюю
   fisher
 
350 - 29.04.21 - 17:12
Убедил. Что-то я с гуидом сразу не допер.
   fisher
 
351 - 29.04.21 - 17:21
Может, в самом деле в текстовые файлики складывать.
По датам генерации гуидов. По часу на файлик, скажем. Текущий час - в регистре сведений. Файлики - только на чтение.
   fisher
 
352 - 29.04.21 - 17:22
В общем, оперативный буфер - в РС, из которого выгружаться в файлики.
   fisher
 
353 - 29.04.21 - 17:25
Просто отдельное хранилище для этой задачи - это из пушки по воробьям. Как сервис для нескольких потребителей - еще куда ни шло.
А для одной базы плюсы есть, но и минусов хватает. Нужно ж это отдельное хранилище сопровождать. А у них всегда своих приколов хватает.
   Garykom
 
354 - 29.04.21 - 17:40
(353) dbf во всех платформах 1С есть
   Garykom
 
355 - 29.04.21 - 17:41
(354)+ Если очень очень хочется "в базе" то засунь эту dbf в хранилище
   fisher
 
356 - 29.04.21 - 17:44
Не. Не хочу dbf. Мне файлики нравятся. Я бы на них сделал.
Сделать папочки на день / месяц / год. Надо достать по гуиду - сразу генерится полный путь к нужному файлику. А они там уже по порядку разложены. Можно хоть тем же двоичным поиском строчку находить.
Управлять удобно. Перенести старый период на бэкап-сервер в архиве - раз плюнуть. Красота.
   Garykom
 
357 - 29.04.21 - 17:46
(356) не тупи файлики тормоза по сравнению с dbf
на dbf можно из 1С cdx сделать и быстро-быстро будет
   Garykom
 
358 - 29.04.21 - 17:47
(357)+ если один файлик dbf большой то можно их много завести, размер в гиг-два нормально
   fisher
 
359 - 29.04.21 - 17:48
(357) Что-то мне подсказывает, что производительность достаточная будет. Хотя я без понятия в ентих алкомарках и чего с ними вытворяют. Может и ошибаюсь.
   fisher
 
360 - 29.04.21 - 17:49
Главное, что производительность будет линейная. Если уж взлетит, то в пути не упадет.
 
 
   fisher
 
361 - 29.04.21 - 17:51
Хотя... Можно же точно также завести по dbf на каждый час :)
Ну, можно. Не придется свой поиск в файле рисовать.
   fisher
 
362 - 29.04.21 - 17:53
Хотя места будет больше занимать. А оно же нам важно типа. Может, лучше текст? :)
   fisher
 
363 - 29.04.21 - 17:57
Просто у нас естественным образом "кластерный индекс" получится. Генерить по нему cdx - избыточно.
   Кирпич
 
364 - 29.04.21 - 18:18
Да в sqlite загнать и всё. Там тебе и кластерный индекс и всё шо хош.
   Ёпрст
 
365 - 29.04.21 - 18:34
(364) не поплохеет база в скульлайте от 50-100 мультов марки ?
   Ёпрст
 
366 - 29.04.21 - 18:34
мне лень тестить, были бы клюшки, попробовал бы.
   H A D G E H O G s
 
367 - 29.04.21 - 18:42
Восстановил 15 млн марок.
3 ошибочные
на конце вместо
150 символа комбинация
эя
   H A D G E H O G s
 
368 - 29.04.21 - 18:42
сейчас буду разбираться
   Garykom
 
369 - 29.04.21 - 18:46
(367) служебные символы попало и обнулило
   H A D G E H O G s
 
370 - 29.04.21 - 18:56
Все, вкурил.
Пустой алкокод у них.

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

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

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

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

Добавлю проверку на четность при архивации
   Garykom
 
371 - 29.04.21 - 19:05
Кто в ЕГАИС советую заранее готовиться к тому что все старые марки и алкокоды к черту
И заставят перемаркировать новыми от ЧЗ
   Garykom
 
372 - 29.04.21 - 19:06
(371)+ Остатки понятно перемаркировать, все проданное нафик
Если старые запасы возвращается то перемаркировка
   Garykom
 
373 - 29.04.21 - 19:10
(371) Но это вряд ли раньше чем https://xn--80ajghhoc2aj1c8b.xn--p1ai/business/projects/beer/about-experiment/
Выйдет в продакшен
   victuan1
 
374 - 29.04.21 - 19:17
(371) Откуда инфа?
   Кирпич
 
375 - 29.04.21 - 19:22
(365) Так любой субд поплохеет. Ну сделай 20 баз. По 5 гигов на базу нормально будет искать.
   Garykom
 
376 - 29.04.21 - 19:26
(374) инфа с пива (373)
"Останется только один" ибо кто крепким торгует тот и пивом тоже
А юзать две разные "маркировки" дико неудобно
   victuan1
 
377 - 29.04.21 - 20:02
(376) Про пиво понятно.
Я про "Кто в ЕГАИС советую заранее готовиться к тому что все старые марки и алкокоды к черту
И заставят перемаркировать новыми от ЧЗ".

Старые марки на крепком алкоголе - почему заставят его перемаркировать?
   Вафель
 
378 - 29.04.21 - 20:30
А кстати в чем отличие акцизных марок (АМ) и федеральных специальных марок (ФСМ)
   Garykom
 
379 - 29.04.21 - 20:32
(377) а нафига ЧЗ в лице ЦРПТ заморачиваться с этими кривыми старыми марками?
   Garykom
 
380 - 29.04.21 - 20:33
(379)+ На все экспериментальные так же забивали и заставляли перемаркировать или разрешали без них до окончания срока годности
А у спиртного срок годности тю
   H A D G E H O G s
 
381 - 29.04.21 - 21:26
(378) АМ - на импорт, ФСМ - отечественное, но с 2021 теперь все - ФСМ.
   Ёпрст
 
382 - 29.04.21 - 21:45
(373) зачет ага, а в Татарстане уже идет пилот по маркировке пива обычными ФСМ.. как на крепкий алкоголь один в один.
Эти клоуны в правительстве всё пирожок не поделят.
   Garykom
 
383 - 29.04.21 - 22:08
(382) есть такое
   victuan1
 
384 - 29.04.21 - 22:10
(382) Игры чиновников - в Татарстане это просто заградительная мера, чтобы не пустить пиво из других регионов. На всю страну не будет эксперимент Татарстана распространен.
   H A D G E H O G s
 
385 - 29.04.21 - 22:31
6 Гб данных и
8 Гб индекса
превратились в
3,3 Гб данных и 
1,3 Гб индекса
   Ёпрст
 
386 - 29.04.21 - 22:36
(385) неплохо.. это с РС ?
   H A D G E H O G s
 
387 - 29.04.21 - 22:37
(386) нет, это справочник Марок
   Ёпрст
 
388 - 29.04.21 - 22:37
(387) ну.. без наименования ? или наименование - китайщина ?
   H A D G E H O G s
 
389 - 29.04.21 - 22:40
(388) Алкокод+Наименование - в китай, в 170 байтную строку.

Отдельный РС с хешами еще не строил
   Ёпрст
 
390 - 29.04.21 - 22:44
(389) я в марках храню не алкокод, а ссылку на справочник алкогольного классификатора. Но, промониторив запросы, нигде это не использую. Вот и думаю, а оно мне вообще надо ? ))) Ну разве что, открыл справочник марки и видишь, че за номенклатура сразу. Хотя, марку, врят ли кто смотрит так.
   Ёпрст
 
391 - 29.04.21 - 22:44
Подумываю, прибить сей реквизит.
   H A D G E H O G s
 
392 - 29.04.21 - 22:49
(390) Полезно иногда ткнуть быстрый отбор в динсписке, но это просто изза лени. У нас гдето в ТСД используется вроде.
   Garykom
 
393 - 29.04.21 - 23:45
Кстати ТС правильно решил сжимать
Гребаные майнеры, гребаная чиа, hdd и ssd самые большие пропали, а средние и мелкие ценник скакнул
   H A D G E H O G s
 
394 - 29.04.21 - 23:53
(393) Ага. Именно под эту новость купил себе в понедельник Sams 980 на 1Тб.
   Garykom
 
395 - 30.04.21 - 00:18
(394) 1Tb ssd еще можно найти но уже убогие бренды/марки
ssd на 2Tb и более уже хрен найдешь
как и hdd >6Tb пропали
благо внешние hdd пока есть на 4-5Tb
   timurhv
 
396 - 01.05.21 - 01:20
Объясните для тупых (для меня), почему китайская раскладка 1 символ занимает 1 байт в SQL. Я прикладник, хотелось бы углубиться в дебри. Суть обсуждения потерял на 3 странице. Можно просто ссылками на матчасть (вики) закидать, там сам буду разгребать...
   ДедМорроз
 
397 - 01.05.21 - 01:48
Какие байты?
Каждый символ кода марки имеет ограниченное число вариантов.
Получается система не по основанию 2,но все равно мы можем последовательность символов перевести в число,а уже число потом перевести в набор байтов (изначально битов).
И SQL умеет хранить символы в отличных от двухбайтовых кодировках,просто,это 1с не умеет.
Хотя,квалификаторы двоичных данных - это как раз для этого.
   ДедМорроз
 
398 - 01.05.21 - 01:54
Кстати,в sms на латинице 160 символов кладутся в 140 байт и никто не считает,что это плохо.
   Вафель
 
399 - 01.05.21 - 08:26
(397) при конвертации из 36 в 256 получаем экономию 30%
Log_256 36
   Кирпич
 
400 - 01.05.21 - 21:24
(396) Всё волшебство в (146)
Китайские буквы получаются случайно
  1  2  3  4  5   

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.