Vasek1209, я предлагаю следующий эксперимент. Разреж 4Тб диск на два по 2Тб.
Один - форматируй в extFat, другой в NTFS. И начинай эксплуатацию. Что там у тебя? Файловая свалка.
Вот пиши активно файлы. Через пол-годика у тебя будет статистика ошибок и проблем.
Есть такая концепция. EAV (entity->attribute->value). Вобщем она предполагает что весь бизнес можно положить всего в 2 таблицы.
Я никогда не любил EAV но здесь мы имеем дело с другим маргинальным случаем. Пожалуй объединение
сходных или однородных таблиц в более крупную - было бы правильным направлением.
Из похожих моделей. Триплеты и квартеты из RDF/SemanticWeb (subject->predicate->object).
Вообще в одну таблицу все пишут.
И квинтеты есть. С иерархией.
Или даже просто документы. Mongo, CouchDb могут быть компромиссом если мы сможем выделить строку которая укажет сразу ключом на таблицу + id row. Композиция этих ключей - ключ документа.
По поводу индексов. Действительно для 50 полей индексы строить нет смысла. Даже оптимизаторы БД часто выбрасывают индекс из плана при таких размерах.
Я с ужасом читаю вопрос и комментарии. До того как начать искать все и везде как делает Google,
хотелось-бы узнать доменную область. Что за данные лежат в таблицах?
Автор описывает саму проблему как epic fail проектирования базы. База создается для облегчения поиска
и для ускорения выдачи результата. Если это НЕ РАБОТАЕТ значит мы либо базу спроектировали неправильно.
Либо очень резко поменяли юзкейс. Тоесть мы стали искать какую-то информацию или МЕТАИНФОРМАЦИЮ
которая ищется крайне плохо и неэффективно. А почему неэффективно? Недостаточно индексов?
Почему так много таблиц? Они создавались каким-то автоматическим процессом? Что это за процесс?
Можем ли мы ТАМ найти ответы.
Просто создается впечатление что мы не разработчики а просто It-археологи которым в руки попала находка
и мы глядим на нее с изумлением и пытаемся понять как это работало. Что-то здесь не так. Подход
полностью дискредитирует процесс разработки и анализа. Так нельзя. Так - неправильно.
psyskeptic, в моем понимании RAID зеркало никогда не взлетал в домашних условиях. Обычно нет у человека такой строчности восстановления и нет таких требований чтоб держать зеркало. Кроме того чем сложнее у вас стек технологий бекапа тем сложнее ситуации вы будете ловить при восстановлении. Повреждение и ремонт зеркала например требует от вас знаний девопса и системного администрирования. И если вам срочно надо достать старую фотографию вашей бабушки с диска но внезапно вас блокирует сообщение о том что зеркало развалено и надо разбираться - вы скорее всего (в следующий раз) прекратите эксплутацию зеркала. Перейдете на более простое. Как я предлагал. По четным неделям один диск. А по нечетным - другой.
Adamos, я признаться ее использовал только в части плагина для Microsoft CosmosDb и еще в части Databrick плагина. Который кажется имеет единственную имплементацию в одной среде. Jetbrains пока еще не догнал.
В целом - красиво хотя расположение менюх достаточно причудливое.
pfg21, давай поищем на сайте Microsoft. Где-то же они указывали цели создания этой ФС. Там ссылка на флешки была точно. Вообще не-журналируемые ФС ставить на магнитный диск в современном мире - это очень плохо. Это я как бывший DBA говорю. Это заканчивается крашем и потерей последних файлов если при нагрузке выключить питание. Журналируемые ФС - обычно способны восстановить свои структуры автоматом при монтировании. Не-журналируемые - обычно провисают в статусе ошибки и требуют ручного вмешательства человека.
Если ты сомневаешся в этом утверждении - давай проведем эксперимент с магнитным диском и exFAT.
Один - форматируй в extFat, другой в NTFS. И начинай эксплуатацию. Что там у тебя? Файловая свалка.
Вот пиши активно файлы. Через пол-годика у тебя будет статистика ошибок и проблем.
Согласен?