Які відмінності між алгоритмами, що використовують структури даних, та алгоритмами, що використовують бази даних?


10

Загальне питання

Які відмінності між алгоритмами, що використовують структури даних, та алгоритмами, що використовують бази даних?

Деякий контекст

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

В даний час я працюю над зміцненням свого розуміння алгоритмів, які, звичайно, сильно залучають структури даних. Це основні структури, такі як Bag, Queue, Stack, Priority Queue та Heap.

Я також щодня використовую бази даних для зберігання даних, які були оброблені та подані кінцевим користувачем або оброблені програмою. Я отримую та передаю дані через DAL, який має власні структури даних, які генеруються на основі таблиць у базі даних.

Мої запитання виникають, коли у мене є можливість сортувати дані за допомогою бази даних, щоб надсилати їх мені впорядкованим шляхом або за зростанням / убуванням, або для завантаження та завантаження даних у мою логіку, обробляти ці дані в черзі пріоритету та сортувати купу все це. Або іншим буде пошук записів за допомогою бази даних, а не завантаження підмножини записів і використання чогось на зразок двійкового пошуку для пошуку запису чи записів, які мене цікавлять.

На мій погляд, я б спробував провести стільки операцій на кінці бази даних, перш ніж надсилати її, оскільки спілкування дороге. Це також змушує мене замислитися, коли ви використовуєте алгоритми та структури даних, строго визначені у вашій власній логіці, а не для обробки даних, ніж даних бази даних?

Тож ось питання ...

Запитання

  1. Які відмінності між структурами даних та базами даних?
  2. Коли ми використовуємо алгоритми, які використовують структури даних, визначені виключно у вашій власній логіці, а не в основі бази даних?
  3. @Harvey post: Коли методи в базі даних стають менш ефективними у використанні, ніж методи за вашою власною логікою?
    • @mirculixx post: Що робить метод ефективним?
  4. @Harvey post: Як обробка даних зі структурами даних швидша, ніж це робиться в базі даних?

Роз'яснення

  1. @ Grant post: Бази даних, з якими я зазвичай працюю, є реляційними, і ці питання виходять із роботи з ними. Однак я вважаю, що ці питання застосовні до будь-якої стійкості (коли я кажу, я маю на увазі це в найбільш загальному сенсі).

Я знаю, що відповіді без конкретного контексту важкі. Їжа для роздумів, порад чи дискусійних питань - це головне те, що я шукаю, і що було б дуже вдячно!


Datomic.com база знаходиться ближче до користувача , ніж традиційні реляційні. Ви дивитесь лише на традиційні бази даних?
Робота

@Job Ні, реляційні бази даних - це не єдине, що я тут розглядаю. Йдеться більше про розуміння різниці між структурами даних у логіці від структур даних у блоці бази даних / стійкості.
hulkmeister

Як правило, я б сказав - використовуйте базу даних, якщо можете, але якщо вона стає занадто повільною, тоді вдайтеся до використання структур даних. Дублювання даних (наприклад, кешування) є поганим, тому що ви повинні тримати їх синхронізовано, тому уникайте цього, якщо ви не можете.
робота

Надіслати дані в базу даних лише для сортування? Як подорожувати навколо блоку, щоб передумати?

Відповіді:


18

Структури даних здебільшого:

  1. Мешканець пам'яті,
  2. Тимчасовий,
  3. Обмежений розмір,
  4. Не повторно вступаючи без додавання таких механізмів, як блокування чи незмінність,
  5. Не сумісні з кислотами ,
  6. Швидкий, якщо вибирати ретельно.

Бази даних здебільшого:

  1. Зв'язаний з диском,
  2. Наполегливі,
  3. Великий,
  4. Безпечно одночасно,
  5. Сумісні з кислотами, з транзакційними можливостями,
  6. Повільніше, ніж структури даних

Структури даних мають бути передані з одного місця в інше та використовуватися всередині програми. Коли в останній раз ви надсилали дані з веб-сторінки на веб-сервер за допомогою бази даних або проводили обчислення на базі даних, яка повністю зберігалася в пам'яті?

Системи баз даних використовують структури даних як частину їх внутрішньої реалізації. Це питання розміру та обсягу; ви використовуєте структури даних у межах вашої програми, але система бази даних - це сама по собі програма.


Стосовно зауваження веб-сервера від веб-сервера, я погоджуюся, що ви б не використовували базу даних там, але я бачу можливість існування сервлета для обробки або перекладу цих даних, щоб вони зберігалися в базі даних. Це між середнім рівнем та рівнем даних, де речі дещо заплутані. Для спрощення запитання, коли методи в базі даних стають менш вигідними для використання, ніж методи з логіки?
hulkmeister

1
Ну, це хліб і масло DAL, чи не так? DAL існують для полегшення переходу між об'єктами та записами баз даних. DAL - це близько 80 до 90 відсотків того, що ви хочете зробити з базою даних, але, для решти від 10 до 20 відсотків, ви можете повернутися до сирої SQL або збережених процедур, оскільки це більш ефективно.
Роберт Харві

У вашому прикладі сортування / фільтрування ви впевнені, що, ймовірно, хочете зробити таку обробку на сервері баз даних. Але ви, швидше за все, отримаєте результат такої обробки як певну форму структури даних.
Роберт Харві

Наведені вами пункти були справді інформативними. Однак у мене все ще щось набридає щодо методів (або алгоритмів), які працюють із базою даних безпосередньо або просто зі структурами даних, строго в рамках логіки або обох. Я переглядаю пункт 6 обох списків, які ви склали, і питання, яке спадає на думку, - як один швидше, ніж інший? Я завжди вважав, що робота з даними в джерелі - це найшвидший спосіб вирішити справи. Ви можете оновити свою публікацію - я її перечитаю.
hulkmeister

1
Бази даних є повільнішими з ряду причин. Не дивлячись на кешування, ви повинні прочитати дані з диска, використовуючи оператор SQL, який потрібно скласти, причому план виконання часто включає декілька таблиць. Процес набагато складніший. Крім того, зазвичай потрібно перенести результат по дроту, де ви перекладете дані в структури даних, щоб ви могли з ним працювати.
Роберт Харві

6

Які відмінності між структурами даних та базами даних?

На абстрактному рівні цього немає - база даних - це структура даних.

На певному рівні бази даних, як правило, мають на меті зберігати дані, як правило, у форматі, оптимізованому як для вставок, оновлень, пошуку, приєднання, так і для іншої мети (або комбінації).

Наприклад, якщо ви порівнюєте таблицю в RDBMS, щоб сказати масив даних, різниця може бути в часі виконання алгоритму, кількості коду, який ви повинні написати, об’єм пам'яті, необхідної для запуску алгоритму, або гнучкість роботи / доступу до даних за межами програми / алгоритму.

Коли ми використовуємо алгоритми, які використовують структури даних, визначені виключно у вашій власній логіці, а не в основі бази даних?

У тенденції я б заперечував

а) використовувати базу даних, якщо вам потрібно зберігати дані таким чином, щоб це було доступно за межі конкретного алгоритму.

б) використовувати власну структуру даних (в пам'яті), якщо важлива швидкість виконання або не потрібна стійкість

Наприклад, якщо ваш алгоритм обробляє записи клієнтів, можливо, ви захочете зберегти ці записи клієнтів (скажімо, щоб знайти всі клієнти в певній області) для подальшого використання якоюсь іншою програмою / алгоритмом і для зовсім іншого призначення (скажімо, щоб знайти найцінніших клієнтів ). У цьому випадку використання бази даних для збереження даних, ймовірно, є хорошою ідеєю.

Однак зауважте, що існує концепція баз даних в пам'яті, які не обов'язково зберігають дані з міркувань продуктивності. Наприклад, Redis або HANA .

Коли методи в базі даних стають менш ефективними у використанні, ніж методи за вашою власною логікою?

Відповідь дуже залежить від обставин та (типу) бази даних, що використовується. Я б перефразував питання на те, "що робить метод ефективним?" Потім це стає вправою оцінювання методів (= алгоритму), якими ви користуєтесь для вашої структури даних проти методів, використовуваних в базі даних. Також дивіться наступний пункт.

Як обробляти дані структурами даних швидше, ніж це робити в базі даних?

Знову ж, це залежить від специфіки. Загалом, обробка даних, що знаходяться в пам'яті, безпосередньо доступних для процесу, який виконує ваш алгоритм, швидше, ніж надсилання запиту в інший процес (у тому ж комп’ютері або через мережу) і прохання повернути результати . Однак якщо дані вже знаходяться в базі даних, відсилаючи їй команду - скажімо, SQL-оператор для об'єднання двох таблиць і обчислення деякої сукупної функції - і отримання лише невеликого резюме або підмножини даних може бути набагато ефективнішим, ніж спочатку передача всіх дані та обчислення результатів на місцевому рівні (використовуючи власні структури даних).


1

Доступ до дисків - це насамперед найдорожче в цій операції, частіше, ніж доступ до мережі (http://serverfault.com/questions/238417/are-networks-now-faster-than-disks). Якщо ваша база даних не розташована принаймні в 1 Гбіт / с і в тій же мережі, що і ваш сервер веб-додатків, продуктивність мережі не матиме значення стільки, скільки продуктивність диска для більших наборів даних. Або якщо ваші дані знаходяться на дуже швидких твердотілих дисках, які будуть швидшими, ніж звичайний доступ до мережі. Крім того, бази даних зазвичай забезпечують механізм IPC, як іменовані канали замість використання TCP / IP, якщо база даних знаходиться на тому ж сервері, що і ваш сервер додатків.

Якщо ви можете зберегти більшість \ загальної структури даних у пам'яті між запитами, то це, як правило, найшвидша ставка. Якщо ви не можете, то важко перемогти хорошу структуру бази даних з нормалізованими таблицями та належними індексами для пошуку та оновлення продуктивності будь-чого, крім невеликих наборів записів, особливо в системі з мільйонами записів.

Реляційні бази даних зазвичай використовують B + дерево або його варіант під кришкою і мають безліч оптимізацій, таких як вирівнювання даних на диску та буферних пулах для записів, які часто отримують доступ. Це робить їх досконалішими при швидкій обробці великих наборів даних, особливо якщо йдеться про агрегацію чи фільтрацію.


Скажіть, будь ласка, чи я маю це право. Застосовуючи сказане, щоразу, коли я замислююся над роботою з даними, якщо я можу зберігати робочий набір кешованим у пам'яті, це швидше. В іншому випадку спробуйте використовувати базу даних для отримання цих результатів або знайти якийсь спосіб залучити більше запитів до бази даних?
hulkmeister

@hulkmeister так, загалом, якщо набір даних дуже малий або база даних віддалена до вашого місцезнаходження в повільній мережі.
Пітер Сміт

0

Що ви маєте на увазі під базою даних? Ви маєте на увазі реляційну базу даних, наприклад MySQL або SQL Server? Реляційна база даних - це структура метаданих, яка підтримує деякий підмножина операцій, визначених реляційною моделлю . Теорія реляційної моделі, яку в основному розробляв Едгар Кодд у 60-х роках.

Реляційна модель дуже загального призначення та гнучка, але це означає, що вона не може скористатися будь-якою перевагою структури даних або моделей доступу. Структури даних корисні, коли ви щось знаєте про дані та як до них можна отримати доступ. Наприклад, якщо ви знаєте, що останні дані, які ви введете в структуру даних, будуть першими потрібними даними, ви можете використовувати стек.

Я назвав реляційну базу даних структурою метаданих, оскільки це, як правило, досить великий пакет програмного забезпечення, який використовує безліч структур даних, таких як стеки, черги, дерева та списки для створення абстрактної структури даних реляційної таблиці.


Вибачте, просто потрібно уточнити, що означає "симпатичний ват" щодо останнього абзацу?
hulkmeister

@hulkmeister, вибачте, що це мало бути "великим", а не "бітним". реляційна модель дуже абстрактна і досить складна. Забезпечення реалізації, яка насправді працює адекватно, особливо, яка забезпечує ACID ((атомічність, послідовність, ізоляція, довговічність), вимагає безлічі досить складних кодів, що працюють за кадром.
Чарльз Е. Грант
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.