Если есть индексация, то используете полностью самописный движок или что-то существующее?
В качестве поискового движка используем тонко настроенный ElasticSearch
Можно ли привести сравнение с dtSearch по вопросу скорости индексации?
Если речь идет о скорости сбора и индексации, а не поиска, то она сравнима с dtSearch при условии сбора данных по сети. По опыту внедрения у клиентов, Ambar собирает и обрабатывает (извлечение текста + ocr + индексация) около 1 млн документов в сутки.
Можете ли привести запросы к dtSearch, которые работали до 5 минут?
Например, запрос "Иванов Иван Иванович" w/5 75 в 4 млн. документов (примерно 400 Гб файлов)
А простые запросы с какой скоростью отрабатывают?
Простые запросы в dtSearch типа ИНН компании, без усложнений, выполняется несколько секунд.
Вы упустили главную деталь статьи — документы в ES большого размера. Если ваши документы небольшие то искать по ним с помощью ES очень легко, если же поле content.text размером 150 Мб вот тут и начинаются оптимизации
Раньше у нас был Jenkins и в нем был скрипт который выполнялся каждый день и удалял старые образы. Сейчас мы перешли на Buddy Works — он умеет удалять старые образы за нас
Вы привели хорошие аргументы. Правильный ли я делаю вывод: выбирая React Native автоматически надо знать Android или iOS чтобы написать что чуть более сложное чем hello-world?
Извините, но живут же как-то фронтендщики со всеми этими миллионами библиотек. Далеко не все их них зависят от Node.js и нативных модулей. Не пробовали ли полифиллы для Buffer и Stream?
Да, я как раз таки один из таких фронтендщиков. Полифиллы пробовал, не удалось прикрутить их к билд-системе React Native.
Более того, это не повод критиковать React Native в противовес Cordova.
Я не говорю что React Native хуже/лучше Cordova, я лишь рассказал что к моему проекту лучше подошла Cordova
Разве мобильный splash-screen — это не просто показать один компонент, а через пару секунд другой?
Чуть-чуть сложней. Т.к. в этот момент js еще не выполняется, то код отрисовки splash screen должен выполнить java машина. Если я не прав, поправьте.
Вы имеете ввиду debian пакеты?
Спасибо!
Ambar затягивает к себе все файлы и хранит у себя
Доступ к файлу через Ambar из его базы данных
В настройках краулера можно указать из под какой учетки ходить. Во время поиска нет разделения файлов по правам
Один индекс, но хитро настроенный. Писали про его настройку:
Здравствуйте,
Используем
В качестве поискового движка используем тонко настроенный ElasticSearch
Если речь идет о скорости сбора и индексации, а не поиска, то она сравнима с dtSearch при условии сбора данных по сети. По опыту внедрения у клиентов, Ambar собирает и обрабатывает (извлечение текста + ocr + индексация) около 1 млн документов в сутки.
Например, запрос
"Иванов Иван Иванович" w/5 75
в 4 млн. документов (примерно 400 Гб файлов)Простые запросы в dtSearch типа ИНН компании, без усложнений, выполняется несколько секунд.
Да, может! Инструкция есть на английском вот тут. Напишите вашу почту в ЛС и мы пришлем вам инструкцию на русском.
Также перед Tesseract мы правильно подготавливаем изображения для лучшего распознавания
Здравствуйте, а какого рода информация вам нужна? Больше информации вы можете найти, например, на нашем landing page: https://ambar.cloud
Это правильно настроенный Tesseract + парсинг любых PDF
К сожалению нет, у меня он так падает с ошибкой. А именно ругался на ошибку в путях, для этого я прописал:
Но этого было не достаточно. Если у вас есть еще какие-либо предложения готов выслушать
Полностью согласен с вами. Нам нужны highlights поэтому поставили
store: true
Вы упустили главную деталь статьи — документы в ES большого размера. Если ваши документы небольшие то искать по ним с помощью ES очень легко, если же поле
content.text
размером 150 Мб вот тут и начинаются оптимизацииЯ считаю что вы не правы. Увеличение скорости поиска в 1100 раз это не "экономия на спичках" — это описание решения конкретной задачи
Раньше у нас был Jenkins и в нем был скрипт который выполнялся каждый день и удалял старые образы. Сейчас мы перешли на Buddy Works — он умеет удалять старые образы за нас
Я рассматривал React Native с точки зрения фронтенд программиста, который знает javascript но не знает мобильной разработки.
Для Джавы и Свифта и так есть библиотеки там бразуреные не нужны. Для RN очень мало собственных библиотек, а старые js библиотеки не работают
Если их нет, то почему же есть бибилиотека для них? react-native-splash-screen
В статье поднимается вопрос о нише React Native.
Тоже использовал этот компонент. Завести его оказалось не просто
Вы привели хорошие аргументы. Правильный ли я делаю вывод: выбирая React Native автоматически надо знать Android или iOS чтобы написать что чуть более сложное чем hello-world?
Да, я как раз таки один из таких фронтендщиков. Полифиллы пробовал, не удалось прикрутить их к билд-системе React Native.
Я не говорю что React Native хуже/лучше Cordova, я лишь рассказал что к моему проекту лучше подошла Cordova
Чуть-чуть сложней. Т.к. в этот момент js еще не выполняется, то код отрисовки splash screen должен выполнить java машина. Если я не прав, поправьте.
Спасибо за комментарий. Расскажите, в каком проекте вы бы использовали React Native? Потому как я не увидел его ниши
Я использую расположение папок, которое предлагает Visual Studio: каждый проект и его proj файл в собственной папке, а sln файл лежит в корне.
Вот
appveyor.yml
с настроенной публикацией в NuGet. Если будут еще вопросы приглашаю в ЛС для обсуждения.