Яка платформа для великої математичної бази даних?

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

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

Спостереження, швидше за все, будуть прочитані з текстового файлу. У кожному записі буде розміщена сітка (2 x ціле число) (рядок і стовпець) (рівень з плаваючою точкою) наземний рівень та різні рядкові інформаційні коди (можливо, до 30 символів).

Сітки можуть мати приблизно 10000 рядків x 10000 стовпців. Не кожне місце розташування в сітці матиме запис у кожному опитуванні, але вони, як правило, мають до ста записів. Багато локальних мереж взагалі не матимуть записів (сайт не буде ідеально прямокутним).

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

Я думаю про можливі варіанти для платформи -

1. Використовуйте програму баз даних. Я не знаю, наскільки вони можуть бути потужними, але гадаю, що вони мали б великі витрати на GUI.

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

3. Використовуєте такий API, як c-treeACE? Я думаю, що це може бути шлях, який пропонує мені ознайомлення з мовою "зроби це, тоді зроби це" (на жаль, це саме так, як я думаю як інженер!). Але я сподіваюся, що закулісне управління пам’яттю та обробкою процесів, що пропонується API, буде кращим за те, що я міг би досягти з величезними масивами.

4. Або я можу це зробити з об'єктно-орієнтованою мовою, і нехай комп'ютер переживає про вимоги до пам’яті. наприклад, якби я зберігав записи як об’єкти із методами та властивостями, які допомогли б мені отримати результати, які мені потрібні, з кожного запису - чи буде це величезна роздута програма порівняно з 3)

Записів, ймовірно, сотні мільйонів, і я хочу мати можливість запитувати та обробляти їх за кілька хвилин, а не годин (бажано, секунд!) На сучасному комп'ютері під керуванням Windows. Якщо точніше, моя i7 - процесор i7 з 6 Гб оперативної пам’яті та 120 Гбіт SSD під керуванням Windows 7 64 біт.

Сподіваюся, хтось встигне поділитися парочкою слів мудрості з новачком.

Існує ряд варіантів, і, будь ласка, не обмежуйте себе моєю відповіддю тут. Зокрема, ви можете знайти корисні бази даних масиву. Моя відповідь стосуватиметься конкретно ваших запитань щодо баз даних на базі SQL.

Мені це здається, що це питання геоспеціальної інформації. Бази даних на основі SQL насправді досить добре використовуються в таких полях, але це також поле спеціалістів у межах баз даних.

Серед баз даних SQL в цій області PostgreSQL з додатком PostGIS вважається однією з найкращих. Якби я був ти, я би тут почав. Основна перевага SQL полягає в тому, що він зберігає гнучкість у дорозі щодо повторного використання ваших даних для використання, про яке ви ще не думали. Це з хорошою геопросторовою підтримкою означає, що ви можете обчислити відстань на великій площі, не турбуючись про специфіку сферичного триггеру.

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

Незважаючи на це, PostGIS все ще може спростити речі, надаючи уявлення та обчислення на 3- та 4-мірних геометричних системах координат.

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

Декларативний вплив мови

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

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

Однак велика різниця полягає в тому, що довгі запити SQL простіше налагодити, ніж довгі імперативні підпрограми, просто тому, що можна швидше звузити місце, де в запиті відбувається несправність.

Як би це працювало

Швидше за все, якщо ви будете їхати цим маршрутом, у вас буде база даних та програма, написані мовою на ваш вибір. Програма надсилатиме запити до бази даних та отримує відповіді. Ви також можете (в PostgreSQL та багатьох інших реляційних БД) розміщувати запити всередині функцій, які потім можуть викликатися програмою, надаючи більше імперативного або функціонального інтерфейсу. Дані зберігатимуться на диску та матимуть доступ до них із окремого програмного забезпечення, ніж ваша програма. Ви також можете підключитися до іншої програми (від MS Access до pgAdmin) та запускати запити або генерувати звіти.

По суті, ви можете думати про RDBMS як про "математичний двигун", який управляє вашими даними, а ваша програма взаємодіє з ним, щоб зробити все, що вам потрібно.