Комментарии 64
Не совсем понял как из 1С в тарантул попадает?
В 1С с помощью подписки фиксируем изменения данных (хранится на случай, если Тарантул в это время отвалился) и сразу отправляем их на простой web-сервис. web-сервис принимает, проверяет формат, передает на app-сервис на LUA.
Т.е. дергается тарантул в момент начала транзакции на стороне 1С? А если по какой-то причине транзакция в 1С не зафиксировалась, а откатилась. Какая реакция в сторону тарантула?
Тема интересная, ждём продолжения!
"… нам нужна in-memory БД" — А чем MS-SQL не угодила? В статье не указывается версия MS SQL, которую использовали, пара слов о том, что рассматривали MS SQL 2017, но никакого сравнения новой версии. Понятно только, что на существующей версии MS SQL намного медленнее, чем на tarantool 2.1, который 2019 года.
Вот лично я не верю, что хорошо настроенный MS SQL с нормальной структурой таблиц и индексов (а не тем, что создает 1С) и на нормальном железе (не мега крутом, а просто нормальном) не справится с подобным количеством запросов.
Все эти данные легко помещаются в оперативку, и при правильной настройке СУБД все будет в памяти…
Все эти данные легко помещаются в оперативку, и при правильной настройке СУБД все будет в памяти…
Загрузка и обработка массива данных из 6 млн. записей в первоначальной SQL-реализации занимала до 20 минут
Вы про MEMORY_OPTIMIZED=ON? Там вроде бы есть разные ограничения, вроде отсутствия btree индексов, nullable полей и тому подобное.
Нет. Самое обычное кэширование в оперативку.
90 тысяч наименований товаров и 700 складов дают нам максимум 63 миллиона записей. На практике, подозреваю, речь идет о не больше чем 10 миллионах.
Вы пытаетесь меня уверить, что MS SQL не сможет обрабатывать несколько сотен запросов в секунду на чтение на таких объемах?
Это надо как то очень извращенно настроить СУБД, чтобы была такая низкая производительность.
90 тысяч наименований товаров и 700 складов дают нам максимум 63 миллиона записей. На практике, подозреваю, речь идет о не больше чем 10 миллионах.
Вы пытаетесь меня уверить, что MS SQL не сможет обрабатывать несколько сотен запросов в секунду на чтение на таких объемах?
MS SQL показал себя лучше и выдохся примерно на 45 запросах.
Это надо как то очень извращенно настроить СУБД, чтобы была такая низкая производительность.
Нет, меня интересует настройка MSSQL для того, чтобы (фактически) хранить всё в памяти без использования диска. Мне показалось, что вы про это. С кэшом всё понятно, однако есть предположение, что у авторов запросы на чтение выполняются во время непрерывной записи данных на диск.
Вы пытаетесь меня уверить, что MS SQL не сможет обрабатывать несколько сотен запросов в секунду на чтение на таких объемах?
Думаю кстати нет, они же по лайку ищут сразу по многим полям, даже с миллионом записей будут проблемы
они же по лайку ищут сразу по многим полям, даже с миллионом записей будут проблемы
Товаров всего 90 тысяч. И поиск по лайку делают отдельно.
Теперь мы ищем в ElasticSearch с учетом морфологии и ошибок по наименованиям/свойствам и другим текстовым полям, а после этого запрашиваем данные о наличии товаров в различных разрезах в Tarantool и возвращаем результат.
Без конкретной структуры 1С, без конкретных запросов, конфигурации оборудования и настроек SQL Server можно долго гадать, но на самом деле умеренно прошаренные 1С-ники и DBA вполне могли уткнуться примерно в такие цифры (там где-то 126 мс на запрос в статье фигурировало по конкретной строке и 15 мс у тарантула).
Запрос по остаткам, если не приложить особых усилий, это соединение 3 таблиц (справочник с фильтром, остатки и движения). Если действовать по рекомендациям 1С (т.е. фильтр по справочнику в параметрах виртуальной таблицы), то четырёх (фильтр отдельно джойнится к остаткам и движениям). Но MS SQL отлично (лучше других СУБД, применимых к 1С) умеет прокидывать фильтр в отдельные таблицы подзапроса.
В любом случае без дополнительных приседаний это в SQL будет что-то типа
SELECT Ref.ref, Reg2.s
FROM Ref
JOIN
(SELECT SUM(Reg1.s) s, Reg1.ref
FROM
(SELECT ref, -s FROM Reg WHERE DateCodition1
UNION ALL
SELECT ref, s FROM RegTotals WHERE DateCodition2) Reg1
GROUP BY Reg1.ref
HAVING SUM(Reg1.s)<>0
) Reg2
ON Ref.Descr like '1293%'(это очень упрощённо! И если писать "как рекомендует 1С", то джойны будут к Reg и RegTotals — так SQL Server работает хуже в данном кейсе)
А каждое изменение остатков это изменение конечного остатка в RegTotals и движений в Reg (и, если обмен данными, то ещё регистрация изменений)
Дальше можно заставить 1С:
- Не брать движения вообще, а брать только из итогов. Для этого, как минимум, не должно быть движений "в будущем"
- Вести отдельный регистр остатков с строкой поиска (если правильно делать, то с индексами там будет правильно)
Тогда запрос станет примерно таким:
SELECT Reg2.ref, Reg2.s FROM (SELECT SUM(Reg1.s) s, ref FROM (SELECT ref, s FROM RegTotalsWithDescr WHERE DateCodition2 AND RegTotals.Descr like '1293%') Reg1 GROUP BY ref HAVING SUM(Reg1.s)<>0 ) Reg2
Но кроме банальных планов запросов и индексов там надо ещё смотреть:
- Работает ли RCSI (он может работать) в 1С.
- Если не работает, то не фигню ли показывают остатки (т.к. тогда запросы с readuncommitted)
- Если не работает, то не уприраемся ли в блокировки?
- Если работает, то не упираемся ли в tempdb
- Не упираемся ли в журнал транзакций (если да, то планируем диски правильно)
- Не упираемся ли в компиляцию запросов (если временные таблицы используем, то легко, у 1С временные таблицы всё время с новыми именами)
- Не упираемся ли в какие-то другие изменения (регистрация в план обмена, например)
- Не упираемся ли вообще в другие механизмы.
Короче, там много всего еще надо посмотреть. 15 мс в тарантуле это в общем-то тоже дофига.
Вот вы тут хотя бы что-то дали, в отличии от автора статьи. Тем не менее, даже того, что тут написано абсолютно недостаточно, чтобы делать выводы о 125 мс или 10 мс.
Я не 1Сник, логики тут не понимаю, на вид запросы очень странные. Но в любом случае, непонятно, что тут с железом, сколько памяти, что с дисками, где расположен журнал, что с индексами, что со статистикой.
Вот если бы можно было бы скачать базу для тестов, тут можно было бы делать выводы.
Я не 1Сник, логики тут не понимаю, на вид запросы очень странные. Но в любом случае, непонятно, что тут с железом, сколько памяти, что с дисками, где расположен журнал, что с индексами, что со статистикой.
Вот если бы можно было бы скачать базу для тестов, тут можно было бы делать выводы.
Я ведь не просто так написал
Вообще, само по себе желание использовать 1С на относительно крупных внедрениях является странным. Когда надо увеличивать производительность — важна возможность «тюнить» узкие места. А при использовании 1С такие возможности ограничены.
хорошо настроенный MS SQL с нормальной структурой таблиц и индексов (а не тем, что создает 1С)
Вообще, само по себе желание использовать 1С на относительно крупных внедрениях является странным. Когда надо увеличивать производительность — важна возможность «тюнить» узкие места. А при использовании 1С такие возможности ограничены.
А нельзя в 1C использовать всякие мат вьюхи созданные вручную или хранимки?
Можно и нужно. Все зависит от конкретно поставленной задачи.
Ниже в комментарии:
Здесь еще нужно понимать, самовольное создание индексов в 1С является нарушением лицензионного соглашения. Начальство на это смотрит крайне подозрительно, потому любой удачный индекс после следует удалить и создать легальными средствами 1С. Зачастую процесс поиска таких индексов выносится на тестовую среду, в исключительных случаях (критическое падение производительности) могут разрешить что-то попробовать на продакшене.
А как вы потом в 1С используете поиск по тарантулу?
с помощью http-запросов. Т.е. в форме 1С ловим нажатие кнопки в поле поиска (событие «ИзменениеТекстаРедактирования») и отправляем запрос с этим текстом тарантулу, затем ответ подгружаем в таблицу значений
НЛО прилетело и опубликовало эту надпись здесь
У вас устаревшая информация насчёт записи в файл, но такая проблема имела место быть в прошлом
НЛО прилетело и опубликовало эту надпись здесь
Скорее всего вы использовали «ЗаписьТекста» в файл, есть новый механизм через «ФайловыйПоток», он работает гораздо быстрее и сравнимо с другими ЯП
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за тесты, как вы сами видите ЗаписьТекста сравнима с python (правда непонятно почему через ФайловыйПоток медленее, так как работает с памятью), думаю это связано больше не с самой записью в текст, а с тем что питон и 1с интерпретируемые ЯП, а java компилируется, скорее всего потеря на цикле
Можете привести код этих проверок?
Я думаю ответ: Кроссплатформа (Win, Mac, Lin, Android, iOS, web) — везде работает
А если много значений в ответе? Первые 10 берете или как?
Какое-то время ушло на осознание, что каждый инстанс Tarantool является однопоточным и нужно поднимать много инстансов для распределенных запросов, а не выжимать всё из одного
…
С помощью двух инстансов Tarantool (мастер и read only, по 4 ядра и 1,5 Гб памяти на инстанс)
Интересно, зачем нужны 4 ядра на инстанс если инстанс однопоточный?
НЛО прилетело и опубликовало эту надпись здесь
А вот ошибка в тексте, спасибо, сейчас исправлю. На самом деле нужно 3 ядра на инстанс. Вот описание .
Осталось остальной 1с на tarantool переписать :)
Bitrix-обмен товарами из 1С не упирается в СУБД MS SQL (или PostgreSQL). Bitrix-обмен упирается в обмен XML-кой зажатой в zip-файл (в ней же и картинки товаров передаются), в передачу через инет (или через локальную сеть) этого файла в Bitrix, и упирается в разбор полученного XML на стороне Bitrix. При разборе этой XML-ки на стороне Bitrix СУБД MySQL хорошо так нагружена.
Как тут помогает Tarantool? Ускорят выборку данных из 1С?
Как тут помогает Tarantool? Ускорят выборку данных из 1С?
Нет, мы не будем передавать количества в MySQL вообще. Да это кастомизация, но битрикс (как и мобильное приложение и мобильные рабочие места сотрудников) будет показывать остатки прямо из тарантула. И да, тарантул отлично держит запросы к товарам и остаткам без дополнительных кэшей.
Пишите свою прослойку (пример www.intervolga.ru/blog/projects/orm-om-nom-nom-ili-tayny-orm-v-1c-bitrix ) по аналогии с MySQLi, MSSQL для Tarantool?
НЛО прилетело и опубликовало эту надпись здесь
Мне очень печалит, до чего дошел Хабр последнее время. Нет, поймите меня правильно, я не против рекламных статей. Я абсолютно уверен, что есть ниша, где действительно Тарантул будет показывать хорошие результаты. Но то, что мы видим в этой статье, это позор автора.
Автор не дает никакой технической информации по тому как осуществлялся поиск в базах данных, а именно примеры запросов, индексы, статистику. Даны лишь какие-то результаты, из которых мы должны сделать вывод, что все плохо.
Затем автором делается вывод, что им нужна in-memory база данных. Нас опять каким-то макаром поставили перед фактом, что
При этом, в следующем абзаце начинается рассказ про Тарантул и ни слова не сказано, как Тарантул решает обозначенные выше проблемы.
После чего, следует нудный рассказ про внедрение Тарантула (и потом, еще волшебным образом Elastic) и вывод, что все хорошо. При этом не сказано ни слова о целостности данных или их сохранности в процессе отказа.
Вы меня простите, конечно, но вот те выводы, которые сделал я.
У нас есть SQL база 1C, в которой у нас 63 млн записей. Даже если представить строки по 500 байт, это меньше 32Гб памяти, т.е. все эти данные могут легко располагаться в памяти. Вместо того, чтобы разобраться с индексами и журналами, докупить копеечной памяти и SSD,
реализовать всю логику на одном MsSql сервере, не потратив силы на контроль целостности данных, клиентам начали врать, что им нужна In-Memory BD.
Конечно же нужна, что лучше, потратить пару дней DBA MsSql и копейки денег на железо или целая команда людей, кто проводит «тесты», изучает Тарантул «без документации», пишет связки еще и с Эластиком. Конечно же второе, что может быть лучше, чем позаниматься прикольными вещами и развести клиента на деньги!
Отмечу еще, что у автора статьи нет самых базовых знаний MsSql, как пишется журнал, как закачиваются данные в память. Но выводы-то делаются!
Автор не дает никакой технической информации по тому как осуществлялся поиск в базах данных, а именно примеры запросов, индексы, статистику. Даны лишь какие-то результаты, из которых мы должны сделать вывод, что все плохо.
Затем автором делается вывод, что им нужна in-memory база данных. Нас опять каким-то макаром поставили перед фактом, что
открытым оставался вопрос сохранения данных в случае сбоя и быстрой их подгрузки. К тому же нужно было придумывать механизм подтверждения обмена данными с 1С..
При этом, в следующем абзаце начинается рассказ про Тарантул и ни слова не сказано, как Тарантул решает обозначенные выше проблемы.
После чего, следует нудный рассказ про внедрение Тарантула (и потом, еще волшебным образом Elastic) и вывод, что все хорошо. При этом не сказано ни слова о целостности данных или их сохранности в процессе отказа.
Вы меня простите, конечно, но вот те выводы, которые сделал я.
У нас есть SQL база 1C, в которой у нас 63 млн записей. Даже если представить строки по 500 байт, это меньше 32Гб памяти, т.е. все эти данные могут легко располагаться в памяти. Вместо того, чтобы разобраться с индексами и журналами, докупить копеечной памяти и SSD,
реализовать всю логику на одном MsSql сервере, не потратив силы на контроль целостности данных, клиентам начали врать, что им нужна In-Memory BD.
Конечно же нужна, что лучше, потратить пару дней DBA MsSql и копейки денег на железо или целая команда людей, кто проводит «тесты», изучает Тарантул «без документации», пишет связки еще и с Эластиком. Конечно же второе, что может быть лучше, чем позаниматься прикольными вещами и развести клиента на деньги!
Отмечу еще, что у автора статьи нет самых базовых знаний MsSql, как пишется журнал, как закачиваются данные в память. Но выводы-то делаются!
1) заводим регистр сведений
2) заводим реквизит «первые 3 буквы» и реквизит «полное наименование», индексируем
3) выполняем запрос с подзапросом (сначало по первым 3 буквам, затем по полному наименованию).
4) получаем свои пикосекунды поиска
Как смасштабировать по нескольким реквизитам и нескольким словам, думаю, понятно.
В данном кейсе никакие эластиксичи не нужны. И миллион записей это копейки. Все это делается средствами 1с или СУРБД (смотря где вас застал этот кейс).
Проверено не раз, сам впервые столкнулся когда нужно было искать по табличке с миллиардами записей весом в 350 гигабайт (микросекунды до получения результата).
2) заводим реквизит «первые 3 буквы» и реквизит «полное наименование», индексируем
3) выполняем запрос с подзапросом (сначало по первым 3 буквам, затем по полному наименованию).
4) получаем свои пикосекунды поиска
Как смасштабировать по нескольким реквизитам и нескольким словам, думаю, понятно.
В данном кейсе никакие эластиксичи не нужны. И миллион записей это копейки. Все это делается средствами 1с или СУРБД (смотря где вас застал этот кейс).
Проверено не раз, сам впервые столкнулся когда нужно было искать по табличке с миллиардами записей весом в 350 гигабайт (микросекунды до получения результата).
По какому принципу вы собираетесь хранить весь текст по товарам и клиентам?
Просто первые три символа для каждого наименования товара, папки, вида номенклатуры, фио клиента, телефона и карты лояльности? Т.е. если у меня наименование «Вертикальный пылесос Samsung», то оператор уже не сможет найти «Пылесос Samsung»?
Или все-таки отдельными словами? Тут непонятный толк от такой фильтрации для, например, карт лояльности и номеров телефонов, т.к. они начинаются одинаково. Хотя здесь вы, наверное, ищете только по полному совпадению и отказываетесь от живого поиска, когда оператор видит фильтрацию в реальном времени. Но кроме этого же есть фамилии/имена, в которых первые 3 буквы повторяются очень часто (вам придется искать и по фамилии, и по имени, т.к. никто не гарантирует, что ФИО внесли в правильной последовательности). По какому принципу вы разбиваете по словам? Например, наименование товара «Браслет КТ 7405708/01-А552-01 01Б760365Ж.» (это реальный товар) как будет разбито? Сколько по вашим оценкам будет занимать первоначальное заполнение такого регистра (регистров?) и насколько хорошо будет происходить обновление данных? Какой объем будет занимать?
И не зависимо от способа заполнения еще вопрос: я так понимаю, что никакого поиска с учетом морфологии и синтаксических ошибок у вас быть не может как у авторов?
Просто первые три символа для каждого наименования товара, папки, вида номенклатуры, фио клиента, телефона и карты лояльности? Т.е. если у меня наименование «Вертикальный пылесос Samsung», то оператор уже не сможет найти «Пылесос Samsung»?
Или все-таки отдельными словами? Тут непонятный толк от такой фильтрации для, например, карт лояльности и номеров телефонов, т.к. они начинаются одинаково. Хотя здесь вы, наверное, ищете только по полному совпадению и отказываетесь от живого поиска, когда оператор видит фильтрацию в реальном времени. Но кроме этого же есть фамилии/имена, в которых первые 3 буквы повторяются очень часто (вам придется искать и по фамилии, и по имени, т.к. никто не гарантирует, что ФИО внесли в правильной последовательности). По какому принципу вы разбиваете по словам? Например, наименование товара «Браслет КТ 7405708/01-А552-01 01Б760365Ж.» (это реальный товар) как будет разбито? Сколько по вашим оценкам будет занимать первоначальное заполнение такого регистра (регистров?) и насколько хорошо будет происходить обновление данных? Какой объем будет занимать?
И не зависимо от способа заполнения еще вопрос: я так понимаю, что никакого поиска с учетом морфологии и синтаксических ошибок у вас быть не может как у авторов?
Про поиск вспомнилось вот это видео на Infostart Event. Видео на 24 минуты, но если в двух словах — там всю большую строку дробили на подстроки по N символов, со сдвигом в 1 (т.е. «Вентил», «ентиля», «нтилятор» и т.д.). Т.е. жертвовали местом на диске (на таблицу и на индекс), но выигрывали по производительности.
Таким образом получим:
1. Затраты на диск (меньше всего волнует, но все же)
2. Более медленное обновление данных. Просто зарегистрировать объект к обмену со сторонней системой намного быстрее, чем обновить все подстроки в регистре поиска + обновить статистику
3. Бессмысленность регистра при популярных комбинациях
А в реальности придется делать подстроку не 6 символов (как в видео), а 3, что только усугубит ситуацию. Т.е. Elasticsearch выигрывает по всем пунктам еще и бонусом вы получаете поиск с учетом ошибок и морфологии. Ведь смысл же реализовать быстрый поиск, а не любыми путями сделать это на 1с пусть и с худшими показателями
1. Затраты на диск (меньше всего волнует, но все же)
2. Более медленное обновление данных. Просто зарегистрировать объект к обмену со сторонней системой намного быстрее, чем обновить все подстроки в регистре поиска + обновить статистику
3. Бессмысленность регистра при популярных комбинациях
А в реальности придется делать подстроку не 6 символов (как в видео), а 3, что только усугубит ситуацию. Т.е. Elasticsearch выигрывает по всем пунктам еще и бонусом вы получаете поиск с учетом ошибок и морфологии. Ведь смысл же реализовать быстрый поиск, а не любыми путями сделать это на 1с пусть и с худшими показателями
Ну так в видео этом и не делают акцент на «это лучший вариант из возможных». Там именно постановка вопроса «а еще вот так можно прямо на 1С, без сторонних средств». Softpoint вообще годами продвигают и продают инструментарий, который позволяет «более лучше» использовать возможности СУБД в обход ограничений платформы.
Я же вам это видео привел как пример (более проработанный) реализации концепции описанной в комментарии выше.
Я же вам это видео привел как пример (более проработанный) реализации концепции описанной в комментарии выше.
НЛО прилетело и опубликовало эту надпись здесь
Несколько лет назад в одной очень большой организации внедряли зарплатный проект на 1С. А он, что называется, «не взлетел». Разработчики голову ломали, админы, сотрудники отдела-эксплуатанта. Перепробовали все что можно, на MS SQL Server шли дидлоки, процесс сбивался. Я там долгое время просил кое-что сделать, но когда все остальное перепробовали- разрешили. Проблему решили 4 индекса по таблицам на 80 мегабайт. Аж запрыгало.
Здесь еще нужно понимать, самовольное создание индексов в 1С является нарушением лицензионного соглашения. Начальство на это смотрит крайне подозрительно, потому любой удачный индекс после следует удалить и создать легальными средствами 1С. Зачастую процесс поиска таких индексов выносится на тестовую среду, в исключительных случаях (критическое падение производительности) могут разрешить что-то попробовать на продакшене.
В дальнейшем была проведена большая работа по анализу кода. Основной объект анализа- процедурный кэш, анализируется в момент наибольшей нагрузки, высоких блокировок и высокой дисковой активности.
Для понимания- по счетчику Page lookups/sec|SQLServer:Buffer Manager удалось установить, что в отдельные моменты запрос данных из памяти сервера достигает 2 Тб в минуту и более (!!). То есть, память используется не как средство ускорения доступа к информации на СХД а как некий математический механизм, эта нагрузка разительно отличается от рабочей нагрузки других серверов.
Выявлялись наиболее ресурсоемкие запросы, оптимизировались индексами либо передавались разработчикам на изменение кода. При системном подходе никаких ин-мемори таблиц и колумнсторе индексов не понадобилось, и так замечательно заработало.
Кроме того, хорошо поработали с флажками трассировки.
На сегодняшний момент проблемы оптимизации 1С возникают только при внедрении новых задач или существенных изменениях (меняются запросы).
Если модератор пропустит- небольшая моя статья на тему оптимизации MS SQL Server
www.digger.dp.ua/optimizaciya-ms-sql-server
Здесь еще нужно понимать, самовольное создание индексов в 1С является нарушением лицензионного соглашения. Начальство на это смотрит крайне подозрительно, потому любой удачный индекс после следует удалить и создать легальными средствами 1С. Зачастую процесс поиска таких индексов выносится на тестовую среду, в исключительных случаях (критическое падение производительности) могут разрешить что-то попробовать на продакшене.
В дальнейшем была проведена большая работа по анализу кода. Основной объект анализа- процедурный кэш, анализируется в момент наибольшей нагрузки, высоких блокировок и высокой дисковой активности.
Для понимания- по счетчику Page lookups/sec|SQLServer:Buffer Manager удалось установить, что в отдельные моменты запрос данных из памяти сервера достигает 2 Тб в минуту и более (!!). То есть, память используется не как средство ускорения доступа к информации на СХД а как некий математический механизм, эта нагрузка разительно отличается от рабочей нагрузки других серверов.
Выявлялись наиболее ресурсоемкие запросы, оптимизировались индексами либо передавались разработчикам на изменение кода. При системном подходе никаких ин-мемори таблиц и колумнсторе индексов не понадобилось, и так замечательно заработало.
Кроме того, хорошо поработали с флажками трассировки.
На сегодняшний момент проблемы оптимизации 1С возникают только при внедрении новых задач или существенных изменениях (меняются запросы).
Если модератор пропустит- небольшая моя статья на тему оптимизации MS SQL Server
www.digger.dp.ua/optimizaciya-ms-sql-server
Круто!
Просьба/совет: Дублируйте на Инфостарте, там хотя бы смогут оценить практическую часть применения и не будут писать пустых комментариев как все плохо в 1С
Просьба/совет: Дублируйте на Инфостарте, там хотя бы смогут оценить практическую часть применения и не будут писать пустых комментариев как все плохо в 1С
я правильно понимаю, что тарантул для этой задачи работает на 3 ядрах и 1.5ГБ памяти в 2.5раза быстрее чем MSSQL в этих же условиях? сколько инстансов тарантула нужно?
Готов согласиться, что индексы просадят инсерты. Но про это ничего не сказано.
Готов согласиться что даже на индексах поиск по %like% может быть медленным.
Но авторы даже не пытались.
На лицо пользовательский подход к типичной задаче DBadmin.
Ищем профайлером кандидатов на отстрел, бьём лицо разработчикам, учим писать запросы.
Вообще, заметил эту проблему в последнее время. Разработчики привыкли не думать о данных. Мол, фреймворк позаботиться обо всем… Грусть...
НЛО прилетело и опубликовало эту надпись здесь
Чего только люди не делают для ускорения 1С. Знаю пример, когда разгоняли узкие места в 8000 раз, вынося обсчет в ПЛИС.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tarantool: история ускорения поиска в 1С