IT в России и мире в реалиях мирового кризиса
1,286,703
7,816
|
Азъ ( Слушатель ) |
| 03 мар 2021 18:59:53 |
Свои 5 копеек в развитие IT России
новая дискуссия Дискуссия 460
Потихоньку и успешно завершилась первая фаза создания собственной среды разработки и одновременно системы хранения данных.
Получилось очень интересно
Когда начинали проект, ставили такую задачу, создание эффективного инструмента для работы с данными, который позволит объединить несколько источников данных в одну аналитическую систему, включая интерпретацию естественного текста. Базовой опцией будет возможность подключения нескольких источников данных с различной структурой, таких как: SQL (с табличной формой), NoSQL (как XML / JSON), неотформатированные тексты. Пользователь сможет работать с данными (делать запросы и получать ответы) без предварительного знания их структуры, синтаксиса, количества источников, что даст возможность в будущем работать с системой в том числе и непрограммистам.
Для тестов ставили себе вот такую задачу и она решена.
- берём JSON с эпизодами сериала
- file: /DataSets/2020_1217/The Big Bang Theory (CBS) pretty.json
- загружаем через интерфейс – получаем связанные узлы, в т.ч. отдельных эпизодов
- можем загрузить и другой подобный файл -- увидеть, что сезоны в т.ч. "магнитятся" друг у
другу
- т.е. явно уже возникает ассоциативная связь -- тут делаем акцент (она возникает автоматически
из-за одинаковых слов в структуре)
- делаем запрос типа "siblings" со входными данными [ "season 1 number 1", "season 1 number 2" ]
- мы получим список сезонов обоих фильмов -- их в этом случае не отделить друг от друга
- даже не разделённые, это отличный результат, т.к. мы вообще не сообщали системе о входной
структуре ничего
- можно добавить в элементы запроса название сериала -- должны остаться только сезоны
именно этого сериала
- такие данные на вход: [ "The Big Bang Theory (CBS) season 1 number 1", "The Big Bang Theory (CBS) season 1 number 2" ]
Сейчас проходим тест уже на промышленных данных.
Получилось очень интересно
Когда начинали проект, ставили такую задачу, создание эффективного инструмента для работы с данными, который позволит объединить несколько источников данных в одну аналитическую систему, включая интерпретацию естественного текста. Базовой опцией будет возможность подключения нескольких источников данных с различной структурой, таких как: SQL (с табличной формой), NoSQL (как XML / JSON), неотформатированные тексты. Пользователь сможет работать с данными (делать запросы и получать ответы) без предварительного знания их структуры, синтаксиса, количества источников, что даст возможность в будущем работать с системой в том числе и непрограммистам.
Для тестов ставили себе вот такую задачу и она решена.
- берём JSON с эпизодами сериала
- file: /DataSets/2020_1217/The Big Bang Theory (CBS) pretty.json
- загружаем через интерфейс – получаем связанные узлы, в т.ч. отдельных эпизодов
- можем загрузить и другой подобный файл -- увидеть, что сезоны в т.ч. "магнитятся" друг у
другу
- т.е. явно уже возникает ассоциативная связь -- тут делаем акцент (она возникает автоматически
из-за одинаковых слов в структуре)
- делаем запрос типа "siblings" со входными данными [ "season 1 number 1", "season 1 number 2" ]
- мы получим список сезонов обоих фильмов -- их в этом случае не отделить друг от друга
- даже не разделённые, это отличный результат, т.к. мы вообще не сообщали системе о входной
структуре ничего
- можно добавить в элементы запроса название сериала -- должны остаться только сезоны
именно этого сериала
- такие данные на вход: [ "The Big Bang Theory (CBS) season 1 number 1", "The Big Bang Theory (CBS) season 1 number 2" ]
Сейчас проходим тест уже на промышленных данных.
ОТВЕТЫ (7)
|
|
Podli ( Слушатель ) |
| 03 мар 2021 19:14:48 |
Цитата: Азъ от 03.03.2021 18:59:53
А как оно поведет себя, когда у вас будет много данных?
ПМСМ если ентой штуке скормить пакет технической документации какого-нить проекта - на выходе будет неудобоваримая каша. Просто потому что куча автоматических ассоциативных связей тут будет вредной.
Как обстоят дела с поиском? При небольшом числе записей тысяч в 200 - сколько оно результат запроса формировать будет? Сколько запросов в секунду переварит?
|
|
Азъ ( Слушатель ) |
| 03 мар 2021 19:43:21 |
Цитата: Podli от 03.03.2021 19:14:48
тут ответ нужно на две части делить
1я - как оно может себя вести чисто теоретически
2я - как легко можно оптимизировать работу и для какого уровня
Каши не будет, т.к. мы только текст на слова разбираем, остальные связи не автоматические. Другие связи нарабатываются, когда выполняются запросы.
Стратегия оптимизации у нас заключается в том, чтобы результаты уже выполненных запросов переиспользовать. Речь о микро задачах на которые распадается каждый запрос.
У нас малая вариативность таких задач, это типа ARM, мало инструкций...
|
adolfus ( Слушатель ) |
| 04 мар 2021 01:05:37 |
Цитата: Азъ от 03.03.2021 18:59:53
Просто для справки – SQL создавался отнюдь не для программистов, а исключительног для пользователей, типа офисных работников, с трудом выучивших таблицу умножения.
|
|
qurvax ( Слушатель ) |
| 09 мар 2021 22:05:52 |
Цитата: adolfus от 04.03.2021 01:05:37
"Сложность системы растет до тех пор, пока не превысит возможности програмиста", надеюсь помните. Современные развертывания мелкомягкого сикуля, с некоторыми из которых я интимно знаком, изобилуют подводными камнями, летающими граблями и еще заминированны, на всякий, блин, случай.
|
|
adolfus ( Слушатель ) |
| 10 мар 2021 11:36:23 |
Цитата: qurvax от 09.03.2021 22:05:52
Я не про микрософт, а про стандарт. Который про SQL. И стандарт этот в парадигме чисто декларативного языка таки микрософтом поддерживается. А вот нужно ли было в SQL понапихать модных парадигм, типа xml и ооп, это вопрос неоднозначный – любой универсальный инструмент всегда проигрывает набору специализированных. Уже были попытки объять необъятное – сначала алгол, потом pl/1, на очереди c++ и sql. Можно уже забиваться, кто из них первый уйдет.
|
|
DarkRaider ( Слушатель ) |
| 04 апр 2021 21:34:01 |
Цитата: Азъ от 03.03.2021 18:59:53
Прошу прощения, но я пока не могу понять какого рода ПО Вы создаёте.
1) Среда разработки - это в Вашем проекте, собственный компилятор/интерпретатор, какой то фреймворк библиотек или функций? или это блокнот с автоподсказкой синтаксиса?
2) Система хранения данных - это серьёзно, снимаю шляпу! Судя по Вашему посту, все внешние источники подвергаются некоей обработке и конвертации в "ваш формат" перед сохранением?
ЦитатаПользователь сможет работать с данными (делать запросы и получать ответы) без предварительного знания их структуры, синтаксиса, количества источников, что даст возможность в будущем работать с системой в том числе и непрограммистам.
3) Судя по этой строчке Вы решили написать яндекс/гугл поиск собственной разработки? Который будет обрабатывать данные сохранённые в Вашей системе хранения?
Цитата- берём JSON с эпизодами сериала
- file: /DataSets/2020_1217/The Big Bang Theory (CBS) pretty.json
- загружаем через интерфейс – получаем связанные узлы, в т.ч. отдельных эпизодов
4) Вы берёте однородные данные из разных источников? Если нет, то у Вас не получается связанных узлов, так как загруженный json сериала, поваренная книга моей бабушки и модный бульварный порно роман, дадут Вам потрясающее количество совпадений по словам. Если же Вы привязываетесь "совпадения только в структуре" - то может быть ситуация когда не будет ни одного совпадения по структуре, например с json мультфильма "Чип и Дейл спешат на помошь" и учебником физики за 8 класс.
Цитата- можем загрузить и другой подобный файл -- увидеть, что сезоны в т.ч. "магнитятся" друг у
другу
- т.е. явно уже возникает ассоциативная связь -- тут делаем акцент (она возникает автоматически
из-за одинаковых слов в структуре)
5) Коллега, возможно не стоит замахиваться на самого Вильяма, так сказать, Шекспира? "Магнитятся" и сходятся пока они исключительно на Вашем наборе данных.
ЦитатаКаши не будет, т.к. мы только текст на слова разбираем, остальные связи не автоматические.
6) Опять непонятка, вроде бы сверху зарождается мощнейщая система обработки данных, со своей системой хранения, средой разработки, некоей предполагаемой системой анализа и интерпретации содержимого, которая позволит выявлять какие то связи в автоматическом режиме на большом массиве случайных данных. К слову, какую часть подготовки интерпретации Вы делаете на этапе получения данных в систему, до начала "целевых" запросов?
Заранее прошу прощения, возможно я задаю слишком много вопросов в надежде на чудо...
Просто на текущем этапе описания, всё что Вы написали и нечто большее умеют делать "большие" СУБД из коробки. Например, тот же мсскуль.
К слову, просто разбивать на слова малоэффективно, потому что ещё есть такие явления как "контекст" и "словоформа", как с этим обстоят дела в Вашем проекте?
ЦитатаДругие связи нарабатываются, когда выполняются запросы.
Стратегия оптимизации у нас заключается в том, чтобы результаты уже выполненных запросов переиспользовать. Речь о микро задачах на которые распадается каждый запрос.
А можно ли пример запроса? Пытаюсь себе представить и не могу...
- На наборе СЛУЧАЙНЫХ НЕСТРУКТУРИРОВАННЫХ данных Вашу систему запросят например так "шёл дождь".
- Структуры - никакой.
- Есть некое абстрактное поле данных, определённым образом обработанное Вашей системой.
- Есть какие то внутренние данные и связи, которые Вы должны были сгенерировать на основе анализа.
Соответственно, получив такой запрос, Вы генерируете некоторые процедуры выборки/обработки данных(микрозадания), которые тут же необходимо сохранить, без привязки к данным. Вероятно, у Вас должна быть развитая подсистема алгоритмизации запросов, способная распознавать типы подставляемых параметров и генерировать динамические конструкции на их основе.
А вот что является результатом обработки запроса, я, пока, даже подключив фантазию, измыслить не могу. Вы что вернёте то? Облако мест вхождения данного словосочетания? Страницы текста? Поток данных?
Заметьте, у условного "Яндекса" - задача проще. Он всего лишь должен проверить свои БД на вхождение слов+словоформ+выдачу генерированных связанных слов по базе текста. И результат - список ссылок, где рейтинг отобранных данных превышает некий порог вхождения.
Цитата: qurvax от 09.03.2021 22:05:52
Позвольте поинтересоваться, про какие непотребства речь?
Волею долга плотно работаю со многими СУБД и наиболее часто именно с MS SQL начиная с 2008, кончая последним. Работаю на всех уровнях, от проектирования информационных систем, промышленной эксплуатации, до архитектуры баз данных и программирования. Каюсь, только начал осваивать машинное обучение на этой СУБД и базы графов (так как в реальных проектах пока не используем), но за все эти годы, как то минули меня печали "подводных камней", особенно с развёртыванием. Возможно, я не заметил какой то важный скелет в шкафу?