Илья Лещенко, может тебе вообще не надо читать Алгоритмы? Я вот читаю ситуативно. Как только возникает вопрос.
Это не то чтение что ты лег на диван и за пару выходных загрузил себе в голову. Так можно Пелевина
читать. Но Алгоритмы ... их надо разбирать. И применять.- Ну тоесть я не вижу смысла их читать
по "приколу".
Илья Лещенко, ладно забей. Я все равно ничего не понял. :)
Чтение книжек и понимание алгоритмов это один скилл. Но написание кода
и использование ЭТИХ алгоритмов - это другой. И там еще - бездна
знаний которых у тебя нет. Зарегайся ради интереса на codewars
и попробуй порешать задачки.
Алгоритмы изучают разработчики не для эстетики а для применения.
Eugene-Usachev, был такой интересный проект Loom для Java. Вобщем была идея,
сохранив исходный код в виде классической мультизадачности на базе Thread, использовать
потоки на базе корутин или фиберов (я уж не помню точно). Сейчас он релизнулся или нет я не знаю.
Он как раз дает возможность запускать большое число потоков (2048) (которые в основном стоят в ожидании
какого-то события) но при этом не потребляют потоков ОС и не преключают контекст потока ОС каждые 20мс
как это делает линукс. Мне эта идея нравится. Она сохраняет структурное программирование
(вся бизнес логика в одном месте а не разбросана по всему коду как в асинхронщине).
В классическом (дефолтном) варианте даже 1000 потоков запускать - уже проблема. Т.к. они
ориентированы на интенсивные вычисления а не на ожидание событий notify или снятия локов.
Неправильные дизайны таблиц - это нормально. Идет эволюция. И аналитики на этапе проектирования
тоже могут всего не знать. Никто вообще не может дизайнить систему с нуля и до релиза. Всегда
идут пробы и ошибки.
Если будете делать нормализацию - сделайте ее в несколько фаз (мажорных релизов).
Например
Тоесть я как-бы говорю. Добавление дочерней таблицы - не деструктивно. Мы можем добавить
и старый софт будет совместим. Но попутно вы можете начать тестировать новый функционал
параллельно со старым. И это здорово. Потом когда все протестировано во второй фазе
вы убиваете поля из родительской таблицы.
Но это очень похоже на Blue-Green deployment только деплоймента нет а есть медленная эволюция
схемы.
Griboks, видимо у вас сработал эффект медленного поступления данных из источников. И имело смысл запускать 8 потоков. Да.
Файловая система вообще не обязана ничего писать до тех пор пока к ней не приходит
явный fsync. Где этот fsync стоит в вашем приложении - неизвестно. Но можно словить разные
эффекты от его применения. Слишком частые фиксации тоже вредны и это я ловил на запуске
записи логов в мультипоточке.
Владимир, я про такие проекты читал еще лет 10 назад в рунете. Я не спец в си-шарпе. Но мне кажется
что такие уже существуют. Для Java был Object Query Language (OQL) и он использовался кажется
в JVisualVm при анализе дампа памяти.
Владимир, я считаю что каждый программист хотя-бы раз в жизни должен написать свою DBMS.
Но это точно не формат вопроса в хабр. Это - блог длиной в несколько лет. И это репозитарий кода
в гитхабе. И для того чтобы разбираться в теме - тебе нужна своя грамматика SQL. Тоесть парсеры.
Нужно знать как работают оптимизаторы. Посмотреть для примера хотя-бы Apache Calcite.
Нужен выбор класса БД. Дисковая. Ин-мемори. Алгоритмы и структуры данных которые там
должны быть реализованы. И много-много обще-системных вопросов (мультипоточка и перформанс)
без которых этот софт не работает.
БД на хеш-таблицах или на коллекциях создает любой дурак но к сожалению дальше одного приложения
они не уходят. Кстати если вы делаете встраиваемую БД в C# то вам вобщем-то SQL не нужен.
Интеграция и ORM просто убивают идею SQL. Ведь идея идет гораздо дальше чем ООП и языки
разработки.
Я вам желаю удачи. Я тоже когда-то хотел писать свою DBMS (нишевую) для специальных кейсов.
Griboks, надо изучить вашу конфигурацию и вашу задачу. Я писал ETL процессы (I/O bounded задача) и понятное дело что на моем десктопе с 1 HDD не было смысла повышать степень параллелизма дисковых операций. Процесс в 1 поток работал обычно быстрее чем процесс в 2-3-4 потока.
Серпинский - скушный. Мне больше нравится кривую Гилберта рисовать. Ей можно заполнять
квадрат непрерывными диапазонами. Например нарисовать распределение IPv4 адресов
по всей площади.
Тоесть ты думаешь что символ квадратный - а он фактически лежит в прямоугольнике (знакоместо)
с пропорциями 200% : 100%.
Это некрасиво. И твоя идея рисовать слешами может выглядеть на экране не так как ты думаешь.
Ты попробуй без программизма просто в текстовом редакторе нарисовать макет.
ksnk, ну да. Для вечного кеша есть даже эффект "отравления". Poisoned cache.
Но если кеш nginx не справляется со своей работой (вы его пытаетесь хачить) то значит
надо пересмотреть саму стратегию.
Я-бы обновил версию приложения так чтобы 100% ссылок обновились. Например в RestAPI
делают версии /api/v1, /api/v2 и так далее. Обновляем версию и старые кеши умерли навсегда.
До перезагрузки nginx или там до чистки диска.
Вот. А по проблеме кеша еще один великий писал. Что в It есть две проблемы. Как назвать
переменную. И как инвалидировать кеш.
Deita, ты-ж понимаешь что они светят на поверхности и от них греют. Если в террасе
много белых или зеркальных поверхностей - то большая часть света уйдет в атмосферу
и никакого эффекта не будет. Я конечно понимаю что их любят за моментальный
(антропо-чувствительный) эффект. Но вы должны считать КПД.
Если у вас люди сидят на террасах - то лучше сделать пленочные шторы которые можно
осенью к примеру быстро опустить и будет тепло.
Это не то чтение что ты лег на диван и за пару выходных загрузил себе в голову. Так можно Пелевина
читать. Но Алгоритмы ... их надо разбирать. И применять.- Ну тоесть я не вижу смысла их читать
по "приколу".