Хорошая идея заключается в обработке большого количества данных непосредственно в базе данных?

55
6

У меня есть база данных с большим количеством веб-страниц.

Мне нужно обработать все данные, которые у меня есть, поэтому у меня есть два варианта: восстановить данные в программе или обработать непосредственно в базе данных с некоторыми функциями, которые я создам.

Я хочу знать:

    сделать некоторую обработку в базе данных, а не в приложении - хорошая идея? когда это рекомендуется, а когда нет? есть ли плюсы и минусы? можно расширить язык до новых функций (внешние API/библиотеки)?

Я попытался найти контент в приложении (работал), но должен был медленно и грязно. Моя озабоченность заключалась в том, что я не могу сделать в базе данных то, что я могу сделать на Java, но я не знаю, верно ли это.

ТОЛЬКО пример: у меня есть таблица под названием Token. На данный момент у него 180 000 строк, но это увеличится до более чем 10 миллионов строк. Мне нужно сделать некоторую обработку, чтобы узнать, является ли слово между двумя маркерами, классифицированными как "Собственное имя", частью имени или нет.

Мне нужно обработать все данные. В этом случае выполнение непосредственно в базе данных лучше, чем извлечение приложения?

спросил(а) 2020-04-04T02:46:13+03:00 3 месяца назад
1
Решение
95

Моя озабоченность заключалась в том, что я не могу сделать в базе данных то, что я могу сделать на Java, но я не знаю, верно ли это.

Нет, это не правильное предположение. Существуют действительные обстоятельства для использования базы данных для обработки данных. Например, если это связано с вызовом множества разрозненных SQL-запросов, которые могут быть объединены в процедуре хранилища, то вы должны выполнить обработку в хранимой процедуре и вызвать хранимый процесс из вашего java-приложения. Таким образом вы избегаете совершать несколько сетевых поездок, чтобы добраться до сервера базы данных.

Хотя я не знаю, что вы обрабатываете. Вы анализируете данные XML, хранящиеся в вашей базе данных? Тогда, возможно, вам следует использовать XQuery, и многие современные базы данных поддерживают его.

ТОЛЬКО пример: у меня есть таблица под названием Token. На данный момент у него 180 000 строк, но это увеличится до более чем 10 миллионов строк. Мне нужно сделать некоторую обработку, чтобы узнать, является ли слово между двумя маркерами, классифицированными как "Собственное имя", частью имени или нет.

Есть ли какой-то индикатор в данных, который сообщает ему собственное имя? Извлечение 10 миллионов строк (очень восприимчивых к OutOfMemoryException), а затем переход через них - не очень хорошая идея. Если есть определенные параметры о данных, которые могут быть помещены в предложение where в SQL, чтобы ограничить количество получаемых данных, это путь, на мой взгляд. Конечно, вам нужно будет объяснять на вашем SQL, проверять правильные индексы на месте, проверять соотношение индекса, тип индекса, все, что будет иметь значение. Теперь, если вы не можете полностью устранить все "неправильные имена", вы должны попытаться избавиться от всего, что можете, с помощью SQL, а затем обработать остальные в своем приложении. Я предполагаю, что это пакетное приложение, не так ли? Если это веб-приложение, то вы определенно хотите создать пакетное приложение, чтобы выполнить настройку данных для вас, прежде чем веб-приложения запросят его.

Надеюсь, мое объяснение имеет смысл. Пожалуйста, дайте мне знать, если у вас есть вопросы.

ответил(а) 2020-04-04T03:03:01.135521+03:00 3 месяца назад
77

Непосредственное взаимодействие с БД для каждой отдельной вещи - утомительная работа и влияет на производительность... есть несколько способов обойти это... вы можете использовать индексирование, кеширование или такие инструменты, как Hibernate, который хранит все данные в памяти так что вам не нужно запрашивать БД для каждой операции... есть инструменты, такие как luceneIndexer, которые очень популярны и могут решить вашу проблему попадания в БД каждый раз...

ответил(а) 2020-04-04T02:46:13+03:00 3 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема