rPman

Воспользоваться штатной утилитой isql, обсуждение и выгрузить в csv

Либо поставить любой адекватный фриварный (или даже заплатить, за удобство оно нормально) типа ems mysql studio или по проще типа laxsql

В вашем случае, даже если числа float, где то нужно хранить 15 000 000 * 500 000 * 4 = 30 000 000 000 000 это 30 терабайт. Это просто линейный блоб, файл в формате 4 байта на число. И это без индексов (они появятся когда вам понадобятся поисковые запросы по выборкам). Не вздумайте брать универсальные базы данных, у вас узкая специализация и практически любое другое готовое решение будет требовать от вас плату либо местом либо процессорным временем.

Никуда от этих чисел вам не деться!.

3 минуты на последовательность умноженные на 15 миллионов штук - это приговор, 31тысчу cpu дней, это вам кластер из тысячи процессоров надо на месяц загружать, и хорошо если можно использовать gpu (это может позволить одной машине делать не десяток вычислений а сотни за раз), тогда обойдетесь десятком инстансев амазона и за пару тройку недель посчитаете.

Поверьте, стоимость места в данном случае настолько мизерная что даже смешно ;)

Вам нужно ускорить вычисления на порядок. Почти наверняка алгоритмы у вас однотипные и еще более вероятно, возможно переиспользование данных из соседних последовательностей где-то из середины алгоритма. И чем черт не шутит, вдруг вам получится хранить не итоговые значения последовательностей а только промежуточные из конца алгоритма вычисления, а как только понадобится конечное число, делать последний шаг вычислений (например если соседние сотня чисел отличаются только последним шагом вычислений в алгоритме, храните в 100 раз меньше данных а на каждое значение выполняйте только последний этап вычислений, даже если это будет занимать секунду это будет хорошей платой за стократную экономию места).

Отличный пример, вам нужно посчитать матрицу якобиана для нейронной сети, изменяя значения весов по одному +e и -e. Т.е. нужно вычислить матрицу N*N чисел где N - количество весов в нейронной сетию Если решать задачу в лоб, это значит нужно O(N^3) вычислений - это дико много. Но, так как для каждого числа из матрицы в нейронной сети меняется только один вес, то почти в половине случаев вычисления веса будут использовать одни и те же числа (особенно если вес изменился в сети близко к ее концу) а значит если хранить промежуточные значения вычислений, можно их опускать. На практике хранить ВСЕ на постоянной основе не по требуется, достаточно используя знания в каком порядке идут вычисления (не важно в каком она будет считаться, пусть например с конца) можно рекурсивно считать нейронную сеть, храня эти промежуточные значения в стеке. Трудоемкость конечно все равно останется большой где то порядка O(N^2*log(N)*...) но за ускорение будет небошая плата в N*log(N) памяти

m-k-m

создайте таблицу - адрес проживания, на которую ссылайтесь как от сотрудника так и от вашей сущности объект и еще откуда угодно (адреса есть у много чего)

p.s. если вам нужны запросы по элементам адреса, не городите велосипед, возьмите КЛАДР. настоятельно рекомендую не дублировать базу у себя а использовать рядом лежащую, кажется там есть готовый api для этого, а вы пользуйтесь его идентификатором, но помните, там не все адреса (это может создать миллион проблем, из-за которых люди дублируют кладр у себя в базе, но тогда начинается геморой с ее обновлениями, можете продублировать структуру но данные первично загружайте из кладр)

p.p.s. https://habr.com/post/214945/
https://habr.com/post/140378/

Практически любая IDE умеет экспортировать результаты в csv или xls
https://www.devart.com/ru/dbforge/ есть для большинства популярных баз данных

А еще сам excell умеет импортировать данные из любой БД, если установлен драйвер ODBC

Делайте идентификаторы такими, чтобы можно было гарантированно их разбить на группы, например с шагом N (макс количество серверов) а стартовое значение сиквенсов у каждого сервера разное (от 1 до N) - назовем это стартовое число 'модуль индекса', таким образом вы сгруппируете данные, и перемещать их можно будет группами, по принадлежности индекса своему модулю индекса (получить его можно взял модуль от индекса по N, если N- степень двойки, то достаточно будет битовой маски).

Вам достаточно хранить, какой индекс модуля размещается на каком физическом сервере, и перемещать данные сразу этими группами, естественно в пределах одной транзакции (открываете транзакцию на обоих серверах, льете данные, по окончанию, комитите на одном, отмечаете в таблице что данные переехали, удаляете, комитите на другом.

Чтобы в процессе переноса на сервере данные не появлялись, сделайте механизмы, отключающие эту ноду от создания новых записей (этакий read/write only) и логирование факта модификации записи по id (дата последнего изменения в каждой таблице - либо используйте штатные механизмы низкоуровнего лога sql-сервера), т.е. таблица, которая будет у вас отвечать за информацию о размещении групп на серверах должна содержать содержать и этот флаг. И да, эту таблицу реплицируйте между серверами штатными инструментами sql-сервера.

Кстати, точно помню, в oracle можно было настроить репликацию данных по условию... не удивлюсь если это есть и у других, тогда за перенос данных между серверами будет отвечать внутренний механизм sql-сервера - это на порядок эффективнее и надежнее чем самописные инструменты.

Сам по себе Microsoft Access не предоставляет инструментов по созданию Web интерфейса, если честно access застрял в прошлом веке и не развивается.

Все развитие перенесено в Microsoft Visual Studio, там есть удобные инструменты по работе с базами данных, с универсальным подключением через драйвера (data source), т.е. вы можете работать как ms access, так и oracle/mysql/postgres/.. excell/text csv
Читать про WebForms технология чуть ли не 2003 года, очень удобная и простая как валенок.

Если вы будете единственным разработчиком ПО я рекомендую не выбирать путь с триггерами и реализации логики на стороне БД. Так как проблем создадите себе много а плюсы этого метода — не прочувствуете.

Разработка всей или части логики на стороне БД удобна в случаях когда нужно 'разделять и властвовать', когда удобно, из соображений надежности разработки и минимизации ошибок (например нарушений логической структуры БД), выделить и оформить соответствующий код на стороне БД таким образом, чтобы логику структуры БД невозможно было нарушить никакими ошибками на стороне приложения (php/java/..). Собственно изначально за кодом на стороне БД эта функция и закреплялась — контроль над целостностью БД.

Просто зачастую не так просто выделить часть логики, которую можно 'красиво' реализовать именно на тригерах и хранимых процедурах. К примеру все что касается интерфейса (или форматов запросов API) глупо реализовывать на хранимых процедурах, а вот методы, к примеру реализующие операции со счетами пользователей (такие как транзакции перевода между пользователями), лучше реализовывать внутри БД в виде хранимой процедуры.

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

'Доступно всем' без вариантов нужно хранить в виде bolean у content, даже хотя бы в виде копии, заполняемой тригером у таблицы content_share.

'Доступно друзьям' и 'Доступно конкретному пользователю'… так ли важно разделять эти понятия. это бы имело смысл, если бы количество действий по созданию нового пользователя и добавлению прав было бы сравнимо с количеством запросов на права доступа, а это маловероятно, наверняка в вашей задаче количество запросов на чтение на порядок (или обычно это логарифм) больше изменений.
Может быть достаточно правила 'Доступно конкретному пользователю', а значит обойдетесь таблицей content_share_user {user_id,content_id}

Дальше, никогда не нужно надеяться на чистую реляционную модель. Делайте дополнительную копию на все, что читается чаще чем пишется в удобном для этого месте. Сериализованный список идентификаторов user_id в content.authorised_list (если это числа, то к примеру через ',' с обязательным ',' в конце), если их количество меньше определенного, удобен для запросов вида like '%12345,%', и ведь его можно заполнять не сразу, а периодически отдельным процессом и очищать по триггеру на изменении. Тогда основная нагрузка ляжет не на выполнение тригера, а на запросы только последних измененных данных, а их обычно не так много.
content
.authorised_list varchar = '123,234,345,' или null — для данных, которые нужно запросить из content_share_user
.authorised_all boolean
content_share_user {user_id,content_id}

А что именно тормозит при выгрузке списка с дубликатами постов? Не устраивает, с какой скоростью обрабатывает distinct, делайте дедубликацию самостоятельно, а чтобы не выгружать сами статьи, сначала получите список id а затем на их основе выгрузите нужные записи из posts
И делать это можно прямо на стороне сервера, складывая id во временную таблицу (in memory)
p.s. кстати, если количество статей за запрос сравнительно небольшое — сотни, вы можете делать это запросом select * from posts where id in (....)

Можно я присоединюсь к вопросу, расширив его до:

Имеется очень большое количество строк (в общем случае, с бинарными данными, конечно было бы лучше). Эти строки очень похожи! Размер строк варьируется в пределах от считанных байт до нескольких десятков килобайт.
лучшее что можно сказать про эти строки, — грубо говоря, это различные сообщения по некоторому количеству шаблонов (их количество тоже заранее неизвестное, но тоже большое, примерно количество сравнимое с log(n)). Нет возможности заранее получить эти шаблоны (источник данных независим), мало того, во времени шаблоны меняются, т.е. могут появляться новые и исчезать старые.

Задача, с некоторым приближением (речь не идет о максимальной эффективности), обнаруживать похожие сообщения, или в терминах описанной выше информации об этих строках — выявить шаблон для каждого сообщения. Уровень эффективности можно определить по размеру патча какого-либо diff-алгоритма (тот же bzdiff).

Если задачу решать нахрапом, то это для каждого следующего сообщения производить сравнение с каждым предыдущим (можно взять некоторое окно во времени), вычислять расстояние (размер diff патча) и брать наименьшее.

Дальше можно оптимизировать на основе предположения что если сообщение A находится на расстоянии от B и если C находится на примерно таком же раасстоянии от B, то расстояние между A и C будет примерно таким же, а значит если хранить матрицу расстояний между сообщениями (не для всех а только проверяемых) то расстояние для не проверенных пар можно вычислять из соседних 'соседних'. Можно даже пройтись по архиву и выявить коэффицент/погрешность, которая накапливается если использовать это вышеописанное предположение (A->B)&(C->B) = (A->C) многократно для A->D, A->E на основе таких же вычисленных B->D и B->E или даже D->E… в общем чтобы вместо трудоемкости N*M получить хотя бы N*log(M) где N — количество сообщений, M — размер окна, количество последних сравниваемых собщений (в этом случае их можно уже считать шаблонами).

Поиграйся так, не идеальное решение но иногда спасает:

SET <hh user=rank>=0;
SELECT <hh user=rank>:=<hh user=rank>+1 AS rank, id FROM menu;

Иногда бывает эффективнее заранее пронумеровать записи пользователей в отдельном поле (однократно старые данные и затем при добавлении и удалении записей заново перенумеровывать), тогда запрос станет очень простым:

select * from статьи t where t.номер<=:limit

sqlite — одна из самых медленных реализаций на запись (на средней win машине от 100ms на транзакцию), даже у ms access быстрее, но чтение шустрое, плюс совместимость высокая (если нужно отдельный файл, значит нужно переносить с машины на машину? а sqlite есть под ВСЕ платформы)

nosql вообще сложно сравнивать с sql, наибольшая скорость (на порядок выше sql), но key -> value создает ограничения, и имеет смысл в основном для document-oriented баз данных, т.е. если у вас есть 1->m то придется сериализовать списки и следить за целостностью самим.

фиктивные таблицы:
select 1 from dual union
select 2 from dual union
…

комбинируя разные такие таблицы, можно много что наворотить… только остается вопрос эффективности, но вдруг это решение будет эффективнее создания специальной таблицы.