Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Насколько я понимаю, рост объёмов RAM и появление персистентности этой самой RAM приведёт к отмиранию понятия Файл, ведь всё можно будет хранить непосредственно в виде программных объектов. Мало кто готов к такой смене парадигмы.
Понятие «файл» связано не с особенностями внешней памяти, а с необходимостью как-то идентифицировать архивные данные. Думаю, со сменой носителя эта парадигма не поменяется. Она естественна для восприятия, в отличии от более сложных структур.
Я говорю про файл как массив байтов, про навигацию по графам, файловый путь и его формы речи не было.
Сколько читаю про это, никак не могу уловить суть. С парадигмой файловой системы и файлов вроде как избавились в iOS. Хотя внутри оно все тоже самое осталось.
Вот пример такой. Сфотографировал я фотографию, скопировал на компьютер, отрадактировал и отправил другу. Как обойтись без «файлов» и что значит программные объекты? Какие проблемы это решает, кроме накладных расходов на сериализацию и десериализацию?
Вот пример такой. Сфотографировал я фотографию, скопировал на компьютер, отрадактировал и отправил другу. Как обойтись без «файлов» и что значит программные объекты? Какие проблемы это решает, кроме накладных расходов на сериализацию и десериализацию?
Можно объяснить это так: файл, как концепция, был введён для того, чтобы хранить, идентифицировать и передавать куски данных в энергонезависимой памяти. Почему назвали «файл» есть много легенд, мне кажется, наиболее верно объясняет ситуацию легенда про картотеку перфокарт, которые были сгруппированы по папкам, то, что сейчас офисные работники называют «файл для бумаг».
Так вот, если разобраться, что такое файл, окажется, что изначально это прямая копия куска (блока) энергозависимой памяти. Если представить, зачем это было нужно, можно понять, что блоки содержали осмысленную информацию, в общем случае, эта информация представляла собой данные, понятные программам. Непосредственные данные, которые обрабатывал процессор в памяти, грузил в регистры и так далее. В общем-то, если посмотреть на файл подкачки, можно понять, чем были файлы изначально.
Сначала это были байты, потом группы байт — числа, потом цепочки чисел, и наконец группы чисел и не чисел, объединенные смыслом. Если посмотреть с современной точки зрения — это и были объекты, структуры, массивы, ссылки, в общем случае, программные объекты, с которыми работает пользовательский код.
Недавно была статья про первый форматы MS Office, так там писали, что по сути файлы .doc это дампы сишных структур, копия информации из рантайма.
Так вот теперь представим, что память в 21-м веке наконец-то стала вся быстрая и энергонезависимая. Сама концепция файлов просто теряет смысл. Объекты в памяти остаются объектами в памяти. Не исчезают, пока пользователь их не удалит или сборщик мусора не вычистит. То есть, функция хранения реализована без файлов.
Функция идентификации так же может быть реализована без понятия файлов, ведь в первую очередь, мы идентифицируем объекты, для них даже есть понятие identity, по содержимому или по идентификатору, или по адресу. А то, что все привыкли называть «файловой системой» на деле является способом адресации в древовидной структуре. Не самой совершенной, кстати. XPath тоже такую функцию выполняет, например. А ведь есть и совсем иные альтернативы, типа системы тэгов.
Остаётся третья функция: передача. Конечно, логично передавать объекты в сериализованном виде (проблемы у этого способа были с самого начала), или в виде дампа памяти, как делали MS. Но сейчас есть много путей передачи содержимого не в виде файлов. Фактически, любая передача данных, как могут рассказать связисты, не основывается на общепринятом понятии файла, тут возможно подходит слово «сообщение», так как помимо пользовательских данных, то есть того, что все называют файлом, есть метаинформация о данных, информация о канале данных, специфичное потоковое разбиение данных.
В целом, вот основные доводы в пользу отказа от понятия файла вместе с отказом от концепции носителей данных, которая и привела к появлению понятия файла.
Кстати, сеть IPFS, с которой мне довелось поработать <https://habrahabr.ru/post/310554/>, тоже изначально никак не связана с понятием файла, оно было введено позже, и, на мой взгляд, в результате получился аналог object-relational impedance mismatch, но уже для объектов/блоков и «файлов». Но люди привыкли к файлам, это надо признать
Так вот, если разобраться, что такое файл, окажется, что изначально это прямая копия куска (блока) энергозависимой памяти. Если представить, зачем это было нужно, можно понять, что блоки содержали осмысленную информацию, в общем случае, эта информация представляла собой данные, понятные программам. Непосредственные данные, которые обрабатывал процессор в памяти, грузил в регистры и так далее. В общем-то, если посмотреть на файл подкачки, можно понять, чем были файлы изначально.
Сначала это были байты, потом группы байт — числа, потом цепочки чисел, и наконец группы чисел и не чисел, объединенные смыслом. Если посмотреть с современной точки зрения — это и были объекты, структуры, массивы, ссылки, в общем случае, программные объекты, с которыми работает пользовательский код.
Недавно была статья про первый форматы MS Office, так там писали, что по сути файлы .doc это дампы сишных структур, копия информации из рантайма.
Так вот теперь представим, что память в 21-м веке наконец-то стала вся быстрая и энергонезависимая. Сама концепция файлов просто теряет смысл. Объекты в памяти остаются объектами в памяти. Не исчезают, пока пользователь их не удалит или сборщик мусора не вычистит. То есть, функция хранения реализована без файлов.
Функция идентификации так же может быть реализована без понятия файлов, ведь в первую очередь, мы идентифицируем объекты, для них даже есть понятие identity, по содержимому или по идентификатору, или по адресу. А то, что все привыкли называть «файловой системой» на деле является способом адресации в древовидной структуре. Не самой совершенной, кстати. XPath тоже такую функцию выполняет, например. А ведь есть и совсем иные альтернативы, типа системы тэгов.
Остаётся третья функция: передача. Конечно, логично передавать объекты в сериализованном виде (проблемы у этого способа были с самого начала), или в виде дампа памяти, как делали MS. Но сейчас есть много путей передачи содержимого не в виде файлов. Фактически, любая передача данных, как могут рассказать связисты, не основывается на общепринятом понятии файла, тут возможно подходит слово «сообщение», так как помимо пользовательских данных, то есть того, что все называют файлом, есть метаинформация о данных, информация о канале данных, специфичное потоковое разбиение данных.
В целом, вот основные доводы в пользу отказа от понятия файла вместе с отказом от концепции носителей данных, которая и привела к появлению понятия файла.
Кстати, сеть IPFS, с которой мне довелось поработать <https://habrahabr.ru/post/310554/>, тоже изначально никак не связана с понятием файла, оно было введено позже, и, на мой взгляд, в результате получился аналог object-relational impedance mismatch, но уже для объектов/блоков и «файлов». Но люди привыкли к файлам, это надо признать
окажется, что изначально это прямая копия куска (блока) энергозависимой памятиКакое это имеет отношение к современным реалиям?
Так вот теперь представим, что память в 21-м веке наконец-то стала вся быстрая и энергонезависимая. Сама концепция файлов просто теряет смысл.Тут нужны какие-то аргументы, все-таки.
Фактически, любая передача данных, как могут рассказать связистыСовершенно не важно, как организована передача данных — там много уровней вложенности, важно что именно пользователь получает в итоге. Если постоянно хранимый контейнер с нужными данными и каким-то адресом для доступа/поиска — то это и есть файл. А как организована файловая система — дело десятое.
Когда Youtube шлёт блоки данных моему браузеру мне совершенно не нужна концепция файла. Как и во многих других кейсах.
> Какое это имеет отношение к современным реалиям?
Байты из RAM до сих пор надо где-то хранить, пока электрики разруливают проблемы.
> Если постоянно хранимый контейнер с нужными данными и каким-то адресом для доступа/поиска — то это и есть файл.
Это и есть объект, а как организована коллекция объектов — дело десятое. Может, связный список, может, хэш-массив «мои документы».
> Какое это имеет отношение к современным реалиям?
Байты из RAM до сих пор надо где-то хранить, пока электрики разруливают проблемы.
> Если постоянно хранимый контейнер с нужными данными и каким-то адресом для доступа/поиска — то это и есть файл.
Это и есть объект, а как организована коллекция объектов — дело десятое. Может, связный список, может, хэш-массив «мои документы».
Тут ещё можно порассуждать, к чему более удобно применять понятие версионности, к объектам или к их сериализованным проекциям. Мета-информация, полиморфизм, иммутабельность, связка понятий, которая давно присутствует в программах и присуща объектам далеко не полностью возможна даже в современных ФС.
Короче, всё что я хочу сказать, появление в ИТ понятия «файл» тащит за собой целый куст последствий, которые как бы есть, и все привыкли, и все знают, а то, что известно, как правило, никто не хочет понимать. И так известно, чего там копаться, воду лить. И так сойдёт.
Короче, всё что я хочу сказать, появление в ИТ понятия «файл» тащит за собой целый куст последствий, которые как бы есть, и все привыкли, и все знают, а то, что известно, как правило, никто не хочет понимать. И так известно, чего там копаться, воду лить. И так сойдёт.
Байты из RAM до сих пор надо где-то хранить
Ramdrive и tmpfs смотрят на это утверждение с сомнением. Swapfs с вами согласен, но с файлами у него как-то не задалось.
Это и есть объект
Память процесса должна быть освобождена при завершении процесса и по-умолчанию недоступна ни для кого кроме самого процесса. Файл же обычно не уничтожается по завершению процесса и может быть доступен многим процессам. Отсюда и различие в уровнях организации доступа — в современных FS у файла могут быть сложные иерархически наследуемые права на доступ в самых разнообразных вариантах. Эти права могут включать в себя отдельных пользователей, группы пользователей или любые другие сущности. Помимо прав у файла есть и разнообразные атрибуты, например, его содержимое может храниться в сжатом или зашифрованном виде, а при удалении будет произведена перезапись содержимого. Добавьте сверху сложную систему журналирования и защиты от порчи данных, снапшоты, логические тома, объединяющие разные носители, порой даже на разных машинах.
Процессам же все эти навороты для большинства объектов не очень-то нужны, достаточно просто свободного блока памяти. Тем не менее, как только дело доходит до хранения и сложных структур и работы с ними, то мы получаем примерный аналог специализированной файловой системы — многие СУБД тоже имеют иерархическую и наследуемую систему разграничения прав доступа, защиту от повреждения данных и т.д.
Можно вас попросить пояснить ход вашей мысли, а то я не совсем понял эту цепочку:
1) вам сообщили, что файл «изначально это прямая копия куска (блока) энергозависимой памяти»
2) вы это отрицаете: «Какое это имеет отношение к современным реалиям?»
3) вам поясняют, что «Байты из RAM до сих пор надо где-то хранить»
4) вы усиливаете своё отрицание примером «Ramdrive и tmpfs смотрят на это утверждение с сомнением.»
И тут же пишете «Тем не менее, как только дело доходит до хранения и сложных структур и работы с ними»
То есть, вы сначала отвергаете утверждение, что файлы нужны для _хранения_ (подчёркиваю — хранения) байтов, и тут же утверждаете то же самое.
Как это у вас получается? Может, я чего-то не так понял?
1) вам сообщили, что файл «изначально это прямая копия куска (блока) энергозависимой памяти»
2) вы это отрицаете: «Какое это имеет отношение к современным реалиям?»
3) вам поясняют, что «Байты из RAM до сих пор надо где-то хранить»
4) вы усиливаете своё отрицание примером «Ramdrive и tmpfs смотрят на это утверждение с сомнением.»
И тут же пишете «Тем не менее, как только дело доходит до хранения и сложных структур и работы с ними»
То есть, вы сначала отвергаете утверждение, что файлы нужны для _хранения_ (подчёркиваю — хранения) байтов, и тут же утверждаете то же самое.
Как это у вас получается? Может, я чего-то не так понял?
Некоторые байты из RAM и «прямая копия куска памяти» — это не одно и то же. Мне это представляется настолько очевидным, что я не посчитал нужным это подчеркивать.
Что же до tmpfs — это пример использования файлов в ситуациях, когда нет необходимости постоянного хранения. Следуя вашей цепочке рассуждений такого феномена вообще не должно было существовать.
Что же до tmpfs — это пример использования файлов в ситуациях, когда нет необходимости постоянного хранения. Следуя вашей цепочке рассуждений такого феномена вообще не должно было существовать.
> мне совершенно не нужна концепция файла
Ну как это не нужна? Вы работаете с конкретным именованным ресурсом. На «человеческом» уровне вы это воспринимаете как видеоролик с названием. Тот же файл.
На уровне видехостинга это… какой-то целостный объект с атрибутами в их хранилище данных. Тот же файл. Потом он сериализуется и по кускам приходит в броузер, который тоже собирает этот же видеоролик у себя в кэше, чтобы воспроизвести.
По сути, ничего, кроме среды хранения, не меняется. Пока данные являются внутренними для приложения, они могут иметь любую «физическую» структуру. Но как только возникает потребность их передавать из песочницы одного приложения в песочницу другого, сразу же возникает и потребность в каком-то переносимом контейнере, с идентификатором и атрибутами. И опять же таки, это тот самый файл.
Ну как это не нужна? Вы работаете с конкретным именованным ресурсом. На «человеческом» уровне вы это воспринимаете как видеоролик с названием. Тот же файл.
На уровне видехостинга это… какой-то целостный объект с атрибутами в их хранилище данных. Тот же файл. Потом он сериализуется и по кускам приходит в броузер, который тоже собирает этот же видеоролик у себя в кэше, чтобы воспроизвести.
По сути, ничего, кроме среды хранения, не меняется. Пока данные являются внутренними для приложения, они могут иметь любую «физическую» структуру. Но как только возникает потребность их передавать из песочницы одного приложения в песочницу другого, сразу же возникает и потребность в каком-то переносимом контейнере, с идентификатором и атрибутами. И опять же таки, это тот самый файл.
Как всегда много воды (не конкретно про Вас, а вообще в подобных рассуждениях на эту тему) и никакой конкретики.
Со времен появления этой идеи, многое изменилось. Компьютеры стали не «вещью в себе», а устройствами, которые активно обмениваются информацией с внешним миром.
Я могу написать приложение, которое хранит в оперативке какие то свои данные и она будет хранить, пока оно будет работать. Представим себе, что оно будет работать вечно, и совсем не волнует сколько отъест оперативки. Ну вот работает приложение, я работают с этими данными. И тут мне захотелось отправить эти данные куда то еще. Способ отправки не важен, это может быть, например, сокет. Как отправлять то будем? Сериализовывать? Если да, то мы опять же возвращаемся к концепции «файлов»
Со времен появления этой идеи, многое изменилось. Компьютеры стали не «вещью в себе», а устройствами, которые активно обмениваются информацией с внешним миром.
Я могу написать приложение, которое хранит в оперативке какие то свои данные и она будет хранить, пока оно будет работать. Представим себе, что оно будет работать вечно, и совсем не волнует сколько отъест оперативки. Ну вот работает приложение, я работают с этими данными. И тут мне захотелось отправить эти данные куда то еще. Способ отправки не важен, это может быть, например, сокет. Как отправлять то будем? Сериализовывать? Если да, то мы опять же возвращаемся к концепции «файлов»
> Как всегда много воды
Это ещё мало, всего один комментарий. Я думаю, аккуратный разбор популярных определений слова «файл» займёт не одну статью.
> мы опять же возвращаемся к концепции «файлов»
В случае с сокетом, скорее, поток. Да почти всегда это будет поток данных. Я не зря упомянул связистов, кстати. Ну, разве что мы повезём грузовик жёстких дисков, да и то, все они могут хранить непосредственно дамп памяти, вместе со снэпшотами софта и прочего.
В любом случае, если мы хотим подвести некое обобщённое понятие под всё это, то понятие объекта подходит лучше хотя бы в силу большего количества охватываемой реальности и оторванности от исторического понятия «файл».
*nix-экосистеме в случае сдвига парадигмы придётся тяжелее всего, наверное.
Это ещё мало, всего один комментарий. Я думаю, аккуратный разбор популярных определений слова «файл» займёт не одну статью.
> мы опять же возвращаемся к концепции «файлов»
В случае с сокетом, скорее, поток. Да почти всегда это будет поток данных. Я не зря упомянул связистов, кстати. Ну, разве что мы повезём грузовик жёстких дисков, да и то, все они могут хранить непосредственно дамп памяти, вместе со снэпшотами софта и прочего.
В любом случае, если мы хотим подвести некое обобщённое понятие под всё это, то понятие объекта подходит лучше хотя бы в силу большего количества охватываемой реальности и оторванности от исторического понятия «файл».
*nix-экосистеме в случае сдвига парадигмы придётся тяжелее всего, наверное.
Вы кажется сути не уловили.
Пример: веб сервер сформировал html страницу и через сокет передал ее в браузер. Браузер отрендерил ее и показал. Браузер мог это сделать и из файла на диске либо загрузив через сокет, да собственно это не важно. Что поменяется при вашей парадигме?
Что есть программные объекты?
Пример: веб сервер сформировал html страницу и через сокет передал ее в браузер. Браузер отрендерил ее и показал. Браузер мог это сделать и из файла на диске либо загрузив через сокет, да собственно это не важно. Что поменяется при вашей парадигме?
Что есть программные объекты?
Вы приводите пример, в котором файлы не используются, а потом спрашиваете, что изменится когда файлы исчезнут. Ответ: в данном примере ничего не изменится.
Кажется, это вы суть не улавливаете, не первый раз уже. Почитайте про файлы, потом про ООП (например), потом про API работы с файлами в том же юниксе. Потом поговорим, а то воинствующее профанство, поощряемое плюсами уже давно надоело.
Кажется, это вы суть не улавливаете, не первый раз уже. Почитайте про файлы, потом про ООП (например), потом про API работы с файлами в том же юниксе. Потом поговорим, а то воинствующее профанство, поощряемое плюсами уже давно надоело.
Зачем вы меня посылаете почитать про ООП, API доступа к файлам, если я и так это знаю и программирую под linux? Давайте конкретики.
Берем «html документ», который представляет из себя набор байтов и сохраняем его не в файловую систему, а в виде записи в какую нибудь базу данных, которая все хранит исключительно в RAM. Программа соответственно читает это дело «с оперативки». Теперь это соответствует вашей концепции?
Берем «html документ», который представляет из себя набор байтов и сохраняем его не в файловую систему, а в виде записи в какую нибудь базу данных, которая все хранит исключительно в RAM. Программа соответственно читает это дело «с оперативки». Теперь это соответствует вашей концепции?
> В любом случае, если мы хотим подвести некое обобщённое понятие под всё это
… а кто эти «мы»? Мы вот тут не хотим придумывать ещё какое-то новое обобщенное понятие. Существующих обобщённых понятий с лихвой хватает для определения того, что у нас есть. Вы хотите придумать одно название, такого себе абстрактного франкенштейна, под которое подвести и файлы, и сетевые пакеты? Зачем?
… а кто эти «мы»? Мы вот тут не хотим придумывать ещё какое-то новое обобщенное понятие. Существующих обобщённых понятий с лихвой хватает для определения того, что у нас есть. Вы хотите придумать одно название, такого себе абстрактного франкенштейна, под которое подвести и файлы, и сетевые пакеты? Зачем?
А межпрограммное или вообще межсистемное взаимодействие. Или что будут выкладывать в интернете? Можно называть по типу: документы, фото и т.д. Но как это все называть объединяющим типом?
Ну почему же, может наконец-то файловые системы заменятся на реляционные или документо-ориентированные бд.
Отличная идея! В конце-концов надо же как-то угробить высвободившиеся ресурсы, чтобы сохранить уровень дискомфорта пользователя от подтормаживания системы.
С ресурсами соглашусь, будет затрачиваться больше. Но при чём тут дискомфорт? Или вы думаете, что рядовому пользователю нужно прям давать работу через SQL? А вот в плане выборки, поиска и т.д. работать будет куда удобнее. Можно спокойно накидать фильмам и музыке жанры в связке один ко многим и затем спокойно выбирать без всякого шаманства и каши в файловой системе. Удобства наоборот добавится. Почитайте хотя бы про закрытую WinFS.
И что собственно это даст?
Вспоминается Palm OS на которой не было файлов и соответствующего API, а память устройства была устроена как набор записей. Не помню правда что там было со сбросом памяти — возможно если полностью разрядить аккумулятор вся память очищалась, но это устройство тогда предполагали частую синхронизацию с ПК, так что постоянно бэкапилось. API для файлов появилось только после добавление sd-карт и внедрялось постепенно.
На мой взгляд без файлов все равно будет довольно трудно. На хабре вроде были статьи посвященные возможной архитектуре системы где нет диска, а все хранится на огромном персистентном массиве RAM.
На мой взгляд без файлов все равно будет довольно трудно. На хабре вроде были статьи посвященные возможной архитектуре системы где нет диска, а все хранится на огромном персистентном массиве RAM.
IBM такие системы выпускает уже десятилетия как.
Почитайте про OS/400 и потомков
https://en.wikipedia.org/wiki/Single-level_store
«In the i5/OS, the operating system believes it has access to an almost unlimited storage array of 'real memory' (i.e., primary storage).… The operating system simply places an object at an address in its memory space.»
Почитайте про OS/400 и потомков
https://en.wikipedia.org/wiki/Single-level_store
«In the i5/OS, the operating system believes it has access to an almost unlimited storage array of 'real memory' (i.e., primary storage).… The operating system simply places an object at an address in its memory space.»
Можно начинать уже сейчас, используя mmap и друзей вместо read/write. Есть конечно оговорки, но для случайного доступа, когда некоторые места могут читаться чаще чем остальные — самое то.
Эхх… вот смотрю и думаю, когда ж станет простому обывателю склепать RAM-диск гигов на 200-300 и не задумываться при этом о продаже почки\печени… Современные г… простите, криворукие кодеры умудряются даже примитивные программы иной раз сделать через такие извращения, что вешается далеко не самый древний комп, и именно на обращениях к постоянной памяти, и даже SSD, увы, не всегда спасает (ибо ресурс, блин..)
" Intel считает, что XPoint может работать в 1000 раз быстрее, чем NAND, и быть в 10 раз более ёмкой, хотя недавно эти заявления слегка уменьшились."
СЛЕГКА — это в 4 раза быстрее вместо обещанной 1000 тысячи раз, и существенно дороже. Я бы сказал, что Intel и Micron крупно облажались и теперь пытаются замаскировать провал.
СЛЕГКА — это в 4 раза быстрее вместо обещанной 1000 тысячи раз, и существенно дороже. Я бы сказал, что Intel и Micron крупно облажались и теперь пытаются замаскировать провал.
Кучка современных DRAMО да, особенно SIMM-ы современные.
…
Перевод на «отстань»
Да, дешёвая память это приятно. Хотя буквально давеча думал, что объём памяти практически перестал быть значимым. Скорость памяти настолько отстала, что теперь является бутылочным горлышком. Сделай сейчас процессор на 40 GHz и он не будет в 10 раз быстрее. Так, процентов на 5-10. Но стоит разогнать память в 10 раз, как скорость работы программ возрастёт на порядок.
Эта статья на ~62% состоит из картинок, причем зачастую абсолютно безполезных. Вы это серьёзно?
С уменьшением стоимости RAM становится возможным загружать базы данных в память целиком, проводить операции над ними и записывать их обратноПрекрасное мнение человека не совсем представляющего себе что такое БД и что такое надежность хранения. Основная задача БД это сохранение данных успешно выполнившихся транзакций при ЛЮБЫХ обстоятельствах (вероятно, кроме прямого разрушения оборудования хранения, и то даже тут есть всякие удаленные кластера и т.п.). Загрузив данные в память и столкнувшись kernel panic, выходом из строя материнской платы, незапуском генератора при незапланированной длительности отключения электроэнергии, перегревом серверной и серверов при выходе из строя системы охлаждения и еще десятком событий, БД в RAM столкнется с потерей транзакций. Иногда одной транзакции бывает достаточно для существенных потерь бизнеса.
Как по мне, как раз ваш комментарий — пример воинствующего невежества. Такие БД мало того, что существуют немало лет и вовсю используются, они уже получили признание. Например, как аналитические БД, или для data mining, позволяя выполнять запросы с недостижимыми для традиционных БД скоростями. Причем исходные данные могут хранится как раз в традиционных БД, обычных файлах, whatever. Большинство из них не обеспечивают ACID, потому что это никому и не нужно — загрузили данные, покрутили так и сяк, построили отчеты и забыли. Хотя многие обеспечивают, и вы получете real-time аналитику и надежность традиционных БД. Многие являются надстройками над традиционными БД. Существуют даже облачные сервисы, которые позволяют вам использовать подобное решение с повременной оплатой, можно, например, построить квартальный отчет и не покупать сотни гигабайт памяти. И с удешевлением оперативной памяти in-memory database и in-memory data grid стали серьезной угрозой аналитическим massively parallel processing БД, таким, как Teradata.
Вообще, даже современные OLTP СУБД по-возможности максимально кешируют данные в памяти, и если есть возможность целиком затянуть БД в ОЗУ, они именно так и делают. Это, конечно, не отменяет необходимости писать на диск журнал транзакций сразу же по мере их выполнения. А в OLAP это вообще общепринято.
«Основная задача БД это сохранение данных успешно выполнившихся транзакций при ЛЮБЫХ обстоятельствах»
это определение однобоко и относится к OLTP процессингу.
например Oracle при возможности затаскивает в память как можно больше. Потому что даже в большинстве OLTP БД чтений происходит намного больше чем записей.
IMHO со временем архитектра серверов БД превратится в систему с гигантской памятью в которой все транзакции будут писаться на персистентную NVRAM для надежности, а оттуда архивные партиции уже на «вечные» HDD (или аналоги) если это необходимо.
это определение однобоко и относится к OLTP процессингу.
например Oracle при возможности затаскивает в память как можно больше. Потому что даже в большинстве OLTP БД чтений происходит намного больше чем записей.
IMHO со временем архитектра серверов БД превратится в систему с гигантской памятью в которой все транзакции будут писаться на персистентную NVRAM для надежности, а оттуда архивные партиции уже на «вечные» HDD (или аналоги) если это необходимо.
В рамках этой статьи, как мне кажется, стоило бы упомянуть проект HP: «The Machine» — компьютер без разделения оперативной и «дисковой» памяти, в качестве которой хотели использовать MRAM.
Только что-то про него ничего не слышно в последнее время.
Только что-то про него ничего не слышно в последнее время.
Я вот чего не понимаю, раз память так подешевела, а скорость её работы стала на порядки выше чем даже самый быстрый SDD, то почему такое решение до сих пор не применяется для пользователей?
> В 2000 году гигабайт памяти стоил более $1000, а сейчас – всего $5.
> по крайней мере, скорость RAM превосходит скорость накопителей на порядок.
Ну давайте подсчитаем, среднемую юзеру не нужно больше 50 Гб на основной системный раздел и все программы. Соответственно исходя из статьи и цены в 5$ за гигабит *50 Gb оперативки = 250$ = около 15 000 руб по текущему курсу.
Для сохранения данных можно использовать какой-нибудь кеширующий SSD диск на котором будут храниться система и все результаты изменний. А на обычном диске (или SSD, зависит от бюджета) будет храниться всё остальное.
При этом получается что такое бюджетное решение позволит ускорить работу компьютера минимум в 10 раз. Почему ещё никто не реализовал такую простую идею?
> В 2000 году гигабайт памяти стоил более $1000, а сейчас – всего $5.
> по крайней мере, скорость RAM превосходит скорость накопителей на порядок.
Ну давайте подсчитаем, среднемую юзеру не нужно больше 50 Гб на основной системный раздел и все программы. Соответственно исходя из статьи и цены в 5$ за гигабит *50 Gb оперативки = 250$ = около 15 000 руб по текущему курсу.
Для сохранения данных можно использовать какой-нибудь кеширующий SSD диск на котором будут храниться система и все результаты изменний. А на обычном диске (или SSD, зависит от бюджета) будет храниться всё остальное.
При этом получается что такое бюджетное решение позволит ускорить работу компьютера минимум в 10 раз. Почему ещё никто не реализовал такую простую идею?
При этом получается что такое бюджетное решение позволит ускорить работу компьютера минимум в 10 раз. Почему ещё никто не реализовал такую простую идею?
Это массово не используется потому что в памяти не сохраняется информация при выключении компьютера. Соответственно, каждый «холодный» старт должен начинаться с того, что система должна будет забить эти 50 Гб софтом с диска.
А так, эту простую идею реализовали более 30 лет назад, когда в MS DOS появился драйвер виртуального диска.
250$
За эти деньги вы можете купить скоростной NVMe SSD со скоростью чтения в пару гигабит/с и в десять раз большей емкости. Смысла сооружать виртуальный RAM-диск как бы и нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Спасибо за память: как дешёвая память меняет вычисления