V7DBNET4.0

  1. Оффлайн

    Djelf

    Посетители

    Сообщений: 6

    Цитата Wirth ()
    Есть, но думаю проект можно прекратить, в связи с потерей актуальности.

    Перспектива проекта, понятна и интересна.
    А актуальность... смотря какая актуальность!
    Если потеря актуальности это "Нет сообщений и баглистов" то это понятно почему.

    Цитата Wirth ()
    Скорость работы регистров расстраивает, нужно оптимизировать.

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

    Количество скачавших - тоже не показатель. Бета версия интересует только интересующихся.

    Честно говоря, я не уверен что sqlite сможет обеспечить приемлемую скорость.
    Надеюсь, что ошибаюсь.
    Прикрепления: 20
    1 мая 2015 - 22:14 / #11
  2. Оффлайн

    andrmit

    Посетители

    Сообщений: 52

    Проект как имел свою нишу на рынке, так и будет продолжать её иметь.
    Не уверен, что некоторые компании, с полностью переработанными конфигурациями, или полностью самописными, готовы финансово переходить на более старшие версии платформы 1С.
    Прикрепления: 20
    5 мая 2015 - 07:21 / #12
  3. Оффлайн

    Djelf

    Посетители

    Сообщений: 6

    Цитата Djelf ()
    Честно говоря, я не уверен что sqlite сможет обеспечить приемлемую скорость.
    Начинаю себя опровергать  biggrin

    Провел тесты на скорость. Не все так плохо, как казалось.

    Проверял элементарный запрос к регистру ПартииНаличие за период с фильтром по Номенклатуре и вычислением приход/расход.
    Повторяемость замеров времени неплохая, как и масштабирование в зависимости от условий.
    То что там цифры в "мс", а не в часах исключительно потому что времени жалко...

    Запрос выполнялся в 8 вариантах.

    1 - запрос 1С из базы ДБФ  -  22мс
    2 - запрос 1sqlite из базы ДБФ  - 1мс
    3 - запрос 1С из базы V7DBNET4  - 65мс
    4 - запрос 1sqlite из базы V7DBNET4 - 8мс
    5 - запрос sqlite из базы DFB к базе sqlite по составному индексу (SP331,DATE,TIME,IDDOC,LINENO,ACTNO)  - 1мс
    6 - запрос sqlite из базы DFB к базе sqlite по индексу iRA328_VIA331 - 1мс
    7 - запрос sqlite из базы V7DBNET4 к базе sqlite по составному индексу (SP331,DATE,TIME,IDDOC,LINENO,ACTNO)  - 5мс
    8 - запрос sqlite из базы V7DBNET4 к базе sqlite по индексу iRA328_VIA331 - 5мс

    Мысли и выводы пока такие:

    Индексы
    Смысла в индексе iRA328_VIA331 нет, sqlite по своему составному справляется на все 100.
    Хлопнул все индексы, с 8.5G база похудела до 5.5. Надо попробовать удалить еще и колонки и пересоздать индексы в стиле sqlite, но думаю размер будет как раз 5.5. Многовато такие индексы кушают!
    Кроме того ну зачем это вообще? При записи делаем двойную или тройную работу. Записываем дополнительные поля, которые занимают 50% полезного объема, а потом их еще и индексируем.

    Кстати, по составным индексам, вопрос на засыпку:
    Как ты обрабатываешь (SP331,DATE ASC,TIME,IDDOC,LINENO,ACTNO), я так понимаю что там ASC должен быть, а то я заметил что в запросе в строке состояния "Обработка документов <дата>" дату колбасит по страшному...

    Скорость
    На дбф базе 1С тупит на обработке данных 22-1 = 20мс
    На dbeng-sqlite 1С тупит на обработке данных 65-8 = 57мс
    Запросы 2 и 4, различие 7мс.
    Непонятный момент: 5-6 и 7-8, 4мс разницы! Откуда лишние 3мс появляются?

    Т.е. судя по всему тормозит преобразование данных sqlite в формат 1С,  с этим можно побороться...
    Прикрепления: 20
    10 мая 2015 - 13:08 / #13
  4. Оффлайн

    Wirth

    Администраторы

    Сообщений: 389

    Цитата
    Как ты обрабатываешь (SP331,DATE ASC,TIME,IDDOC,LINENO,ACTNO), я так понимаю что там ASC должен быть


    Цитата
    Кроме того ну зачем это вообще? При записи делаем двойную или тройную работу. Записываем дополнительные поля, которые занимают 50% полезного объема, а потом их еще и индексируем.
     
    Я не обрабатываю составные индексы, а заставляю это делать саму 1С. Результат записываю в дополнительные поля, и их уже индексирую.

    Прикрепления: 20
    19 мая 2015 - 12:28 / #14
  5. Оффлайн

    Djelf

    Посетители

    Сообщений: 6

    Сори, не додумал, desс индексов то в 1с нету.
    Надо попробовать все индексы пересоздать на asc и посмотреть что получится...

    А насколько сложно отказаться от индексов 1С? Или это вообще невозможно?
    Я понимаю, для создания работоспособной системы это было отличное решение!

    Теряется же довольно много возможностей и оптимизаций, пока вот что увидел:

    1. sqlite умеет брать данные из индекса т.е. "select Номенклатура from ПартииНаличие where data что то там" возмет id номенклатуры из своего составного индекса "номенклатура,дата", а с индексом 1С это не получится и Номенклатуру придется читать из таблицы. Мелочь, но приятно!
    2. Классический пример: "select количество from ПартииНаличие where Склад = AND Номенклатура = " у тебя видимо  будет использован индекс по складу, а sqlite cможет выбрать индекс по Номенклатуре, ориентируясь на данные ANALYSE.
    3. Созданые пользователем индексы (а это может быть очень вкусно!), я так понимаю, сейчас движок ограничения ставит только по 1С индексу, т.е. работать не будут.
    4. Автоиндексы sqlite - аналогично.
    5. Прямые запросы (если доступ к таким будет) должны будут напрямую указывать индекс 1С и конструировать условие через контактацию строк. Ну гадость же wink
    Прикрепления: 20
    20 мая 2015 - 20:51 / #15
  6. Оффлайн

    Wirth

    Администраторы

    Сообщений: 389

    Цитата
    А насколько сложно отказаться от индексов 1С?
    Сложно. Индексы 1С (CodeBase) - деревья. 1С находит подходящий узел дерева по ключу поиска, и перебирает подчиненные листья и вперед, и назад.
    Ключ поиска 1С формирует на основании специальных классов унаследованных от общего предка CKeyObj. По сути, ключ поиска - это часть строки ключа составного индекса.
    Вот тут и возникает сложность. Адаптировать индексные выражения CodeBase к sqlite вполне возможно. Но нужно еще транслировать ключи поиска 1С в условия SQL, здесь пока засада. Я думаю над решением.

    Но решать нужно. Огромный минус текущей реализации в том, что из не 1С будет практически невозможно добавлять данные, т.к. для заполнения полей с ключами индексов необходим сам 1С.
    Прикрепления: 20
    21 мая 2015 - 11:22 / #16
  7. Оффлайн

    Djelf

    Посетители

    Сообщений: 6

    Немножко не понял: 1С выбирает индекс еще до dbeng32? Тогда это точно засада.

    Заполнение полей можно решить модулем расширения к sqlite, и загрузкой этого модуля расширения (это не сильно сложно).

    Ну я в любом случае записываюсь в тестеры...
    Так что если будет что дать на проверить, то давай.
    Прикрепления: 20
    21 мая 2015 - 17:58 / #17
  8. Оффлайн

    cmd.exe

    Посетители

    Сообщений: 1

    Возможно получить сей продукт на потестить?
    22 января 2016 - 18:07 / #18
  9. Оффлайн

    Wirth

    Администраторы

    Сообщений: 389

    Проект остановлен. Много другой работы, да и клиентов на 7-ке не осталось.
    Если будет интерес, можно подумать в сторону публикования исходных кодов. Конечно, если найдутся умельцы с желанием продолжить начатое.
    1 апреля 2016 - 10:47 / #19