#database #postgresql #optimization
#База данных #postgresql #оптимизация
Вопрос:
Я хочу создать миллион таблиц с двумя столбцами.. ну, я попытался создать с использованием java, для чего потребовалось около 100 МБ данных, преобразованных в 7 ГБ, и потребовалось 20 часов, чтобы завершить это… Я использую postgre sql, перед которым я пробовал mysql, mysql еще хуже .. Есть ли какой-нибудь способ создать такое большое количество таблиц, используя меньше места и времени? будет ли хорошо работать горизонтальное разделение?
Я пытаюсь проиндексировать данные RDF для быстрого выполнения, идея состоит в том, чтобы проиндексировать данные rdf с использованием СУБД и преобразовать запрос sparql в запрос sql, ну а RDF — это набор ресурсов в виде троек subject, predicate, object, существующие методы используют таблицы предикатов, значит, для каждого предиката хранятся субъект и объект, количество предикатов намного меньше по сравнению с другими 2. Таким образом, для запроса требуется объединение этих таблиц предикатов, чтобы получить результаты, которые имеют порядок 100 МБ в плоских файлах.Я пытался создать тематические таблицы 4 быстрое выполнение
Комментарии:
1. с какой стати вы хотите это сделать?
2. может быть, вы могли бы рассказать нам, почему вы этого хотите, и люди могли бы дать вам совет по лучшему решению.
3. Звучит как проблема X-Y .
4. Очевидно, что вам не следует пытаться создать таблицу с двумя столбцами.
Ответ №1:
Если вам нужен миллион таблиц в вашей базе данных, вы делаете это неправильно.
Таблицы предназначены для представления структурно и концептуально отличающихся данных. И я отказываюсь верить, что вы оперируете миллионом различных концепций в своем приложении.
Иногда новички считают, что им следует создать таблицу для каждого пользователя, например. Но «пользователь» — это одно понятие, и вы храните одну и ту же информацию для каждого пользователя (например, имя, адрес электронной почты, имя пользователя, пароль), поэтому это должна быть одна таблица, где каждый пользователь — это просто отдельная строка.
Похоже, вы совершаете аналогичную ошибку, возможно, не с пользователями, а с какой-то другой абстракцией, экземпляров которой у вас много. Каждый экземпляр должен представлять собой строку в одной отдельной таблице.
Если вы опишете нам, что именно вы пытаетесь сохранить в базе данных, мы почти наверняка сможем помочь вам разобраться, как это следует отображать в таблицы.
Редактировать
после прочтения ваших комментариев (которые действительно следует отредактировать в самом вопросе), вот мои мысли:
Если все данные структурированы одинаково (в виде троек), вы могли бы просто сохранить все в одной таблице с тремя столбцами, а затем добавить необходимые индексы для эффективного поиска.
Если все предикаты известны заранее, вы могли бы создать таблицу для каждого предиката, но я не совсем уверен, насколько это имело бы смысл, даже.
Вероятно, самым чистым вариантом было бы иметь 4 таблицы:
(id, subject) , (id, predicate) , (id, object) , (subjectid, predicateid, objectid) .
Комментарии:
1. спасибо за ваш повтор, я думал очень наивно, я пытаюсь проиндексировать данные RDF для быстрого выполнения, Идея состоит в том, чтобы проиндексировать данные rdf с помощью rdbms и преобразовать запрос sparql в sql-запрос, ну, RDF — это набор ресурсов в виде троек subject, predicate, object, существующие методы используют таблицы предикатов, для каждого предиката хранятся субъект и объект, количество предикатов намного меньше по сравнению с другими 2. Таким образом, для запроса требуется объединение этих таблиц предикатов, чтобы получить результаты которые имеют размер порядка 100 мб в плоских файлах. Я пытался создать таблицы subject tables 4 для быстрого выполнения.
2. Как я уже указывал в предыдущем посте, существующие методы используют таблицы предикатов .. проблема в том, что если у нас есть 10 объединений в таблице предикатов, потребуется несколько часов, чтобы вернуть результаты. Ex query (?p живет в ? l) итак, p — это person, а l — местоположение, объединяющееся с (?p имеет имя kunal), поэтому из результата первого запроса я хочу проверить, у какого человека есть имя kunal .. и некоторые другие объединения.. Моя идея заключается в поиске предиката в таблице subject или object, а не в поиске ssubject в таблице predicate.
3. @kunal: это звучит как плохая идея по ряду причин. Просто реляционные базы данных предназначены для работы не так. Но помните, что поиск по строкам (я предполагаю, что все три поля являются строками) является довольно дорогостоящим. Посмотрите на мое последнее предложение, которое потенциально могло бы значительно ускорить процесс (вместо поиска всех троек, где субъектом является kunal, вы можете просмотреть kunal один раз в таблице subject, а затем получить идентификатор субъекта, который вы можете искать в таблице троек (которая для каждой тройки просто сохраняет идентификатор в каждой из таблиц subject, predicate и object)
Ответ №2:
Таблицы базы данных занимают довольно много места для управления своими индексами, схемой и резервирования дискового пространства.
В большинстве случаев вам будет лучше иметь одну таблицу с 20 миллионами строк, чем миллион таблиц с 20 строками.
Если подход с 20 миллионами строк стал слишком большим, вы могли бы использовать вертикальное разбиение, чтобы повысить его производительность.
Я действительно думаю, что вы в основном преуспеете в том, чтобы предоставить пользователям Stack overflow массовый аннуитет, пытаясь понять, почему вам нужно делать то, о чем вы просите 🙂