0. unpete 527 08.08.17 11:09 Сейчас в теме

Зачем 1С-нику NoSQL и CRDT

В статье речь пойдет о современных инструментах для хранения, транспорта, обработки и обмена данными на примере популярной NoSQL-базы CouchDB.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. starik-2005 1864 14.08.17 11:07 Сейчас в теме
Дочитал до производительности и понял, что автор как-то сильно занижает скорость работы. Для 1С и СУБД соглашусь, но тут сама 1С сильно усложняет INSERT, а вот про NoSQL - как-то бедновато получается с производительностью.

Сам тестил в свое время тот же MySQL - в 300 потоков на AMD FX 8320 удалось записать 1кк (тот самый миллион записей) за 80 секунд (т.е. 12500 записей в секунду, по 1-й записи, а не пачкой). Это при отключенном кешированиии на обычный HDD (Seagate, 7200, 3000Gb, 64Mb кеша). Если кеширование включить, то те же данные в 5 потоков записываются за 25 примерно секунд (дальше потоки роли не играют, т.к. физически упираются в прочее железо, т.е. дальнейшее увеличение количества потоков уменьшает производительность). Все тестилось на PHP с либой pThreads.

Тестирование REDIS внутренним бенчмарком показывало скорость на уровне 100к запросов в секунду, включение режима именованных потоков (ключ --pipe) увеличивало производительность в 5-8 раз (до 500к-800к запросов GET/SET в секунду). На новом Ryzen 1600 3200MHz скорость была еще выше - до 2кк SET/GET в секунду (два миллиона записей в одну чертову секунду!)

Так вот, на райзене текстовый конвейер через sed в поток redis-cli 110 миллионов недействительных паспортов из CSV-файла базы ФМС грузит за 4 минуты, в Postgres с fsync=off через COPY в таблицу без индексов грузит 15 минут (но потом достаточно медленно выбирает), а в MS SQL - за 20 минут (но уже с индексами и на более мощном железе, конечно). Т.е. не все так печально, как Вы пишите. Просто 1С не умеет так работать и не дает возможности на это повлиять.
kote; WizaXxX; +2 Ответить
3. unpete 527 14.08.17 13:25 Сейчас в теме
(1)
автор как-то сильно занижает скорость работы

Я упомянул в тексте, что цифра относится не к сырой записи, а к реальной задаче, в которой создаются элементы справочника Номенклатура, наименования этих Номенклатур заполняются случайными словами русского и английского языков и эти элементы отправляются в CouchDB.
Здесь справочник Номенклатура от metadata.js - его не надо путать с одноименным справочником типовых 1С.
Говорить о количестве запросов в секунду бессмысленно в отрыве от размера тела этих запросов.
Если документ имеет вложение в виде медиафайла размером в гигабайт, вряд ли получится записать 1000 таких документов в секунду.
5. starik-2005 1864 14.08.17 13:32 Сейчас в теме
(3)
Если документ имеет вложение в виде медиафайла размером в гигабайт, вряд ли получится записать 1000 таких документов в секунду.
Так и об одном в секунду тут говорить бессмысленно.

Но я о другом - если хотите показать масштаб разницы, то он действительно есть, но не 150/2000/5000.

По поводу версий, кстати, то не во всех NoSQL они есть (если говорить о ключе объекта и версии). Например, в REDIS есть несколько вариантов хранения данных; простой - ключ/значение, мультисет - ключ, несколько значений; хеш-таблица - ключ->ключ->значение; стек/очередь (LPUSH/LPOP|RPUSH/RPOP). Ну и возможность обмена, реализующая целостность (когда в результате система возвращает старый объект, меняя его на новый), Верисионирование здесь возможно в хеш-таблице, где версией будет второй ключ, но это лишь один из вариантов применения.
4. brr 179 14.08.17 13:32 Сейчас в теме
(1) "Просто 1С не умеет так работать и не дает возможности на это повлиять." - и это проблема
7. unpete 527 14.08.17 13:39 Сейчас в теме
(4)
и это проблема

Никакая это не проблема. Просто, не надо пытаться решить все задачи на одной платформе.
1С хороша для настольных учетных систем. В этом качестве её и надо использовать.
Для высоконадёжных, высоконагруженных и автономных систем есть другие инструменты.
AlexK_2012; WizaXxX; +2 Ответить
2. Darklight 18 14.08.17 13:19 Сейчас в теме
Лично до меня автор так и не смог донести ключевую мысль всей статьи - это как же решается конфликт разных версий при обновлении одного и того же документа? Резюме автора свелось к тому, что программисту это нужно будет решать самостоятельно! Ну и что же ему для этого даст CouchDB? Возможность читать все версии для принятия решения? Но этого мало! Вот бизнес-процесс параллельного многоэтапного согласования. Положительная или отрицательная резолюция согласующего лица может изменить направление движения процесса согласования на тот или иной маршрут. Изменить общее состояние согласования на одно или другое значение. Узел не определяет приоритет (на изменение маршрута влияет только статус согласующего лица). В одном узле маршрут и состояние изменилось в одну сторону, в другом в другую. А потом, ещё до синхронизации, снова поменялся на какую-либо ветвь. И как это всё синхронизировать, какой маршрут и состояние будет в итоге? Всё ложится на плечи программиста - пиши алгоритм, который будет копаться в версиях и восстанавливай правильное состояние? А что делать с сопутствующими данными - другими, связанными, документами и состояниями, которые были изменены в процессе движения по карте маршрута? При небольшом желании для достижения той же ситуации ниаккой CouchDB не нужен - сойдут и регистры сведений 1С - где разные версии согласования просто будут зарегистрированы отдельными записями, с отделеным ключём, - и опять таки, программисту нужно писать код - который всех их будет сводить в одно общее, итоговое состояние.
for_sale; +1 Ответить
6. unpete 527 14.08.17 13:34 Сейчас в теме
(2)
автор так и не смог донести ключевую мысль

Вынужден повторить лозунг Окнософта: "Если вы знаете способ решения вашей задачи без metadata.js - не надо тратить время на изучение наших технологий."
8. starik-2005 1864 14.08.17 13:44 Сейчас в теме
(2)
А что делать с сопутствующими данными - другими, связанными, документами и состояниями, которые были изменены в процессе движения по карте маршрута?
Я так понимаю, что речь идет о "транзакционной целостности". Сейчас тоже, если не установить исключительные блокировки изменяемых данных, 1С при чтении исторических значений будет видеть некое одно состояние. Вот Вы начали транзакцию, прочитали, изменили, записали изменения. В это время 20 секунд ждет вторая транзакция, которая уже прочитала данные до изменения и ждет на записи пересекающихся элементов. Что вторая транзакция запишет? Что нужно сделать программисту 1С, чтобы вторая транзакция записала данные с учетом изменений, произведенных первой транзакций? При этом пользователь, который в форме задачи нажимает ролевую кнопку точки процесса, вообще ничего может не знать о том, что кто-то уже повел процесс по другой ветке. Т.е. без дополнительного кода и на 1С Вы ничего не сделаете.

С точки зрения того же REDIS, то в нем есть аналог транзакций - это множественное изменение (начало изменений, окончание изменений). Если устанавливать флаг блокировки элемента процесса через обмен (пишем истину и смотрим, что там было), то можно реализовать логику блокировки, аналогичную объектной блокировке. Если прочитали истину, пытаясь заблокировать объект, то это значит, то объект уже заблокирован. А с учетом того, что данные в REDIS можно хранить определенное время, после которого они удалятся, то это позволит не парится на тему зависших процессов (как это бывает в 1С, когда при падении клиента или сервера в системе остаются висеть блокировки, которые без рестарта сервисов 1С никак не снять).
9. Darklight 18 14.08.17 14:39 Сейчас в теме
(8)Я просто хотел увидеть весомое преимущество NoSQL подхода - я его не увидел :-(
23. for_sale 720 26.09.17 20:22 Сейчас в теме
(8) По-моему, Вы немного не о том ответили, о чём писалось в комментарии, на который Вы отвечали. Там человек говорил о том, что для многих (осмелюсь заявить - большинства) задач в 1С вот эта многопоточная несогласованность - она не просто не нужна, а вредна.

А Вы пишете, что её можно решить - и в 1С, и другими средствами. Да, можно, но какое преимущество даёт тот же коуч, например? Я вот тоже так и не понял - какое. Пока что мне кажется. что никакого. Боль и страдания блокировок - это не боль и страдания 1С, это сущность решаемых задач. Карту бизнес-процесса действительно нельзя запускать параллельно в нескольких узлах. Документ действительно нельзя записывать сразу двумя пользователями. Последний ящик пива со склада действительно нельзя списать одновременно двум покупателям. И никакая уличная магия с последующей конкуренцией версий тут не поможет - когда спишут то, чего нет. Блокировки здесь - это не наказание, а средство решения прикладной задачи. Можете её на 1С решать или на САПе или через блокнот и батники - Вам всё равно её нужно будет решить так, чтобы в любой момент времени данные были актуальны. А когда Вы начнёте реализовывать блокировки на коучах - рано или поздно создадите свой 1С с преферансом и поэтессами. С 1 записью в секунду и 1С справляется, тут коучи не нужны.

И об этом как раз и говорят те взрослые пользователи Коуча, которых в пример привёл автор - Пейпэлы, Линкедины и т.п. У них совершенно другие задачи. Если есть миллион пользователей, каждый из них имеет свою область данных (свой профиль-баланс), с которыми может работать только он, когда запись в область данных ведётся только одним пользователем, а другие пользователи чужие профили могут только читать - тогда да, скорость выходит на первое место, потому что актуальность данных подразумевается самой задачей.

И, соответственно, наоборот, если в 1С Вы решаете задачи, где область данных защищена правами (кнопку в бизнес-процессе может нажать только один пользователь, каждому складу сопоставлен менеджер с правами), тогда да, имеет смысл глянуть на варианты.
24. starik-2005 1864 26.09.17 21:07 Сейчас в теме
(23)
Там человек говорил о том, что для многих (осмелюсь заявить - большинства) задач в 1С вот эта многопоточная несогласованность - она не просто не нужна, а вредна.
Возможно, ибо автора, который писал то, на что отвечал я, тут пока нет и прояснить свой тезис он сейчас не может (может и сможет попозже). Но вот в том сообщении некоторые слова:
Лично до меня автор так и не смог донести ключевую мысль всей статьи - это как же решается конфликт разных версий при обновлении одного и того же документа? Резюме автора свелось к тому, что программисту это нужно будет решать самостоятельно!
На мой взгляд, отсюда непросто вывести то, о чем говорите Вы (про "для многих хрен забить на эту согласованность - единственный подход") )))
EMelihoff; +1 Ответить
25. for_sale 720 27.09.17 11:24 Сейчас в теме
(24)
На мой взгляд, отсюда непросто вывести то, о чем говорите Вы (про "для многих хрен забить на эту согласованность - единственный подход") )))

Так и не нашёл, где я такое говорил. Я как раз говорил, что забить хрен на согласованность в 1С нельзя, даже если придётся забить хрен на скорость.

Лично до меня автор так и не смог донести ключевую мысль всей статьи - это как же решается конфликт разных версий при обновлении одного и того же документа? Резюме автора свелось к тому, что программисту это нужно будет решать самостоятельно!

С этим я полностью согласен. Я тоже так и не понял, где тут преимущество Коуча для 1С. В статье много отсылок на какой-то скрипт (насколько я понял, автор его продаёт), много каких-то с любовью описанных приложений, решающих какие-то узкоспециализированные задачи, для которых дан функционал, но почти ничего не сказано о реализации.

Более того, автор в самом начале сам говорит о том, что Коуч ставит целостность данных на второе место после скорости и распределённости. Вот тут как раз и нет пояснения, как Коуч может решить большинство задач в 1С. Да и не ставил автор, по-моему, такой цели. Статья описывает решение конкретных узких задач с помощью нового инструмента. А многие почему-то восприняли его как - залить свою старую БД керосином и бежать подключать Коуча))
27. starik-2005 1864 27.09.17 13:09 Сейчас в теме
(25)
Так и не нашёл, где я такое говорил.
Вы говорили о том, что для большинства задач в 1С многопоточная согласованность не нужна (даже вредна). Не? Я же говорю о том, что основная задача 1С - изменить данные в базе в соответствии с данными, полученными от пользователя. Если это просто регистрация факта финансовой деятельности, в котором есть 100% информации, то не нужна. На мой же взгляд, куда большее количество задач изменения информации так или иначе но используют исторические данные (при продаже товаров уже определяется, есть ли КЗ, какова себестоимость партий, после чего КЗ и себестоимость списываются или добавляется ДЗ, которая будет закрываться уже документом оплаты, а если товары/услуги агентские/комитентские, то все еще сильнее усложняется).

Фактически NoSQL (но не в том виде, как пишет автор статьи) из-за очень высокой скорости можно использовать для синхронизации многопользовательской или многопоточной работы с данными. В 1С в действительности не так много задач, которые бы в пределе не требовали бы той самой многопользовательской согласованности. Просто не на каждом предприятии это нужно, хотя перепроведение документов встречается повсеместно и производится весьма небыстро.
10. panvartan 14.08.17 16:14 Сейчас в теме
Интересно, что 1с, имея собственную, хоть и хромую на обе ноги, модель данных, могла бы, при желании, работать на любой nosql базе, эмулируя необходимый sql функционал на уровне своего сервера.
11. starik-2005 1864 14.08.17 16:34 Сейчас в теме
(10)
эмулируя необходимый sql функционал на уровне своего сервера
Вся проблема в том, что не все можно сэмулировать в NoSQL для SQL. Вообще, ORM реализуется на NoSQL куда лучше/проще/нагляднее, чем на SQL. В SQL - это идентификатор объекта, занимающий колонку, а в NoSQL - это ключ, по которому можно взять объект. Но если у объекта, например, есть табличная часть (или несколько), то уже на каждую строку каждой таблицы для каждого объекта придется сгенерировать ключ. Помимо прочего усложняется поиск по значению конкретной колонки, т.е. если нам нужно выбрать все документы и их движения за период. Также NoSQL в большинстве своем не умеет толком агрегировать данные, т.е. получить сумму всех документов определенного типа за период будет нетривиальной задачей, ибо у нас тут нет колонок - храниться ключ и объект, в котором уже хранятся каким-то образом колонки. Обычно алгоритм для решения подобной задачи в NoSQL сводится к тому, что читаются все документы (в ключе можно зашифровать, например, тип и дату, тогда поиск упростится), которые мы можем получить (для получения объекта необходимо предъявить ключ, а где мы его возьмем?), а потом проверить дату, после чего просуммировать суммы. Т.е. такая задача для NoSQL решается совсем не просто. А вот доступ к конкретному значению ключа в NoSQL просто безумно быстр.

Если рассмотреть, например, инфраструктуру современных HiLoad-сервисов (например, Stack Overflow), то там есть и Redis, и MS SQL, и другие технологии, которые применяются для разных задач. Для кеширования юзается NoSQL, для хранения данных - обычный SQL.

С точки зрения 1С, NoSQL может применяться очень обширно. Например, на нем достаточно несложно запилить кешер для многопоточных процедур, оперирующих общими данными (или даже для однопоточного проведения документов, когда в кешере сохраняются данные об остатках товаров/задолженности/партии/.... - зачем каждый раз лезти в SQL, если можно получить почти мгновенно данные из NoSQL, передав в отдельный поток данные для формирования значений регистров накопления, т.е. массив движений/наборы записей с установленным отбором по регистратору). Вот для этого NoSQL интересен, а для сборки отчетности с кучей временных таблиц, соединений и прочего - он просто не предназначен для этого.
nvv1970; корум; +2 Ответить
13. panvartan 15.08.17 14:48 Сейчас в теме
(11) Спасибо за подробный ответ. Я просто хотел сказать, что если 1с так старательно абстрагируются от таблиц , то зачем им sql в базе данных? Очень похоже, что от лукавого - сами не могут, а другим предлагают. Что касается неудобства NoSQL для структурированных запросов, то они достаточно успешно там эмулируются
15. starik-2005 1864 16.08.17 11:16 Сейчас в теме
(13)
то они достаточно успешно там эмулируются
Кстати, да. Я так понял, что они просто запилили для обращения к данным механизмы SQL. Думаю, что это сделано для того, чтобы те, кто привык к SQL, могли попробовать новые механизмы практически не меняя подход и рассматривая данные, как таблицы. Но если попробовать реализовать какой-нибудь серьезный отчет на 1С к данным (ну, например, собрать ДДС), организованным в NoSQL, то без изменения подхода можно получить ту же производительность (если не меньшую). Правильным решением будет смена парадигмы, а не попытка все засунуть в формат аля-SQL.
panvartan; +1 Ответить
20. AlexanderKai 18.08.17 13:57 Сейчас в теме
(15)
Правильным решением будет смена парадигмы, а не попытка все засунуть в формат аля-SQL.

Есть альтернативный вариант - map/reduce.
21. AlexanderKai 18.08.17 14:00 Сейчас в теме
(15)
то без изменения подхода можно получить ту же производительность (если не меньшую).

Производительность упирается(на уровне логики БД) как обычно в индексы и в статистику. Ну и еще в распределенность(или отсутствие таковой).
19. AlexanderKai 18.08.17 13:52 Сейчас в теме
(11)
Суммирование происходит так же как и в SQL. Для этого есть вторичные индексы.
Если нужен механизм типа регистра накопления с расчитанными остатками и оборотами - это делается поверх того механизма который предоставляет NoSQL(насчет всех БД не уверен), так же как и в случае с SQL.

Но основная фишка NoSQL, как я думаю, в распределенности. Опять же есть она не у всех NoSQL.
В Couchbase, например если нужно добавить производительности, достаточно просто добавить ноду и произойдет ребалансировка.

Но если у объекта, например, есть табличная часть (или несколько), то уже на каждую строку каждой таблицы для каждого объекта придется сгенерировать ключ.


Объект, может хранится как JSON. За счет этого достигается древовидная структура объекта, с любым количеством таблиц внутри. Ключ остается один. Для всего объекта.
12. starik-2005 1864 15.08.17 11:08 Сейчас в теме
Кстати, тут интересные штуки народ пилит: Интерпретатор 1С-подобного языка на Go. В принципе, с формами на метадата уже можно будет жить без 1С. Типа, "спасибо, большой желтый брат, но ты нам больше не нужен" )))
14. baton_pk 392 16.08.17 10:05 Сейчас в теме
(12)
с формами на метадата уже можно будет жить без 1С

до этого ооочень далеко. у метадаты немалый такой порог входа сейчас - с ходу простому одинэснику не разобраться.
16. kiruha 375 17.08.17 09:54 Сейчас в теме
Я не совсем понял - база данных целиком на CouchDB или параллельно c SQL Server ?
Если целиком - что прям все запросы (и методы связанные с БД) 1С транслируются в запросы CouchDB ?
Или это параллельный функционал хранения данных
17. unpete 527 17.08.17 14:51 Сейчас в теме
(16) База целиком на couchdb, для сложных выборок данных используются map/reduce индексы в тандеме c alasql (SQL запросы к массивам данных в RAM)
18. kiruha 375 18.08.17 11:24 Сейчас в теме
(17)
Спасибо.
Но вот в если есть код
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
|	Номенклатура.Ссылка
|ИЗ
|	Справочник.Номенклатура КАК Номенклатура";

Результат = Запрос.Выполнить();

что в данном случае произойдет ?
Запрос будет автоматически транслирован в запрос к couchdb ?
22. unpete 527 18.08.17 15:02 Сейчас в теме
(18)
Но вот в если есть код [...] что в данном случае произойдет ?
Ничего не произойдёт. Metadata.js ничего про код 1С не знает. Она для тех, кто хочет программировать на javascript, используя аналоги 1С-ных объектов.
В метадате есть документы, регистры и справочники. Они во многом похожи на 1С-ные, но во многом и отличаются.
26. spezc 563 27.09.17 13:01 Сейчас в теме
Если не стоит проблема "списать того чего нет", тогда и блокировка не нужна. Тот же пример с банком - если он примирился с неактуальностью данных и риском двойного списания, тогда он выбирает коуч и иже с ним. Если у бизнеса актуальность стоит на первом месте - тогда никакой коуч имхо не спасет. Все зависит от задач.
for_sale; +1 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Бизнес-аналитик 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

Программист 1С
Москва
Полный день

Консультант-аналитик 1С
Москва
Полный день

Консультант ERP-систем
Москва
Временный (на проект)

Бизнес-аналитик 1С
Москва
зарплата от 90 000 руб. до 150 000 руб.
Полный день