[SQL-noob] об индексе и протирании дырки на ssd
> протирании дырки на ssd
на современных ssd такой проблемы нет.
на старых ssd проблема решается выбором специализированной файловой системой
на современных ssd такой проблемы нет.
на старых ssd проблема решается выбором специализированной файловой системой
Как можно разумно минимизировать этот эффект?на современных ssd, кмк, не забивать диск под завязку.
на современных ssd, кмк, не забивать диск под завязку.afaik, на современных ssd для ротации используются все сектора, в том числе и занятые
Что за задача такая? 240Гб SSD я вижу стоит 500$ . Сколько времени ты собираешься писать ПО под эту фичу?
Что за задача такая? 240Гб SSD я вижу стоит 500$ . Сколько времени ты собираешься писать ПО под эту фичу?встроенный контроллер на компактфлеше 4Гб. Софт уже есть и работает для винтов. У меня задача просто адаптировать программными методами, если нужно будет, и системными настройками.
Пока ещё изучаю вопрос существования специальной БД для хранения логов и возможности перехода на неё.
встроенный контроллер на компактфлеше 4Гб.а файловая система какая используется?
а файловая система какая используется?ну вообще думал об ext2
ну вообще думал об ext2возьми специализированную под flash и это решит твои проблемы: JFFS2, YAFFS, LogFS и т.д.
http://en.wikipedia.org/wiki/Flash_file_system
Несколько не твой случай, но вот такая вот маркетинговая брошюрка:
http://www.emc.com/collateral/hardware/white-papers/h5967-le...
Мы высносили tempdb и transaction log в случае MS SQL и TEMP и redo log для OracleDB на зеркала из двух SSD-шек. Данные в обоих случаях оставались на HDD. В обоих случаях FS была NTFS. Было это год назад. SSD пока живы.
http://www.emc.com/collateral/hardware/white-papers/h5967-le...
Мы высносили tempdb и transaction log в случае MS SQL и TEMP и redo log для OracleDB на зеркала из двух SSD-шек. Данные в обоих случаях оставались на HDD. В обоих случаях FS была NTFS. Было это год назад. SSD пока живы.
двух SSD-шеку ТС, к сожалению, флэшка(вернее даже memory card а не ssd, поэтому у него едва ли проблема решается самом картой или контроллером. и поэтому все-таки стоит проблему решить с помощью специализированной фс
возьми специализированную под flash и это решит твои проблемы: JFFS2, YAFFS, LogFS и т.д.In contrast to JFFS2, YAFFS and UBIFS, LogFS also provides a (very) basic, slow support for use with block devices
У меня обыкновенный компакт-флеш, он уже содержит контроллер и является block устройством. Соответственно LogFS на нём работает хреново, а остальные вообще не работают, так как они умеют работать только на mdm
Графики, которые показывать, заранее определены? Или всякий разный анализ данных будет нужен, непредсказуемый?
У меня обыкновенный компакт-флеш, он уже содержит контроллер и является block устройством.кстати пишут, что:
On most contemporary flash memory devices, such as CompactFlash and Secure Digital cards, these techniques are implemented in hardware by a built-in microcontroller. On such devices, wear leveling is transparent and most conventional file systems can be used as-is on them.
http://en.wikipedia.org/wiki/Wear_leveling
зы
потрать тысячу рублей и убей две compact flash:
одну забив ее под завязку и записывая данные в одно и тоже место;
а вторую пустую, записывая в одно и тоже место
и засеки сколько они продержатся.
это тебе даст достоверную информацию: надо тебе что-то городить или нет
Графики, которые показывать, заранее определены? Или всякий разный анализ данных будет нужен, непредсказуемый?Анализ данных не нужен, график отображает зависимость группы величин от времени записи в лог
Анализ данных не нужен, график отображает зависимость группы величин от времени записи в логНу тогда зачем MySQL и все прочее? Просто складывать на диск уже сгенерированный график — не вариант?
Ну тогда зачем MySQL и все прочее? Просто складывать на диск уже сгенерированный график — не вариант?изменение шага отображения, детализации, границы области обзора, масштаба осей, списка видимых величин
изменение шага отображения, детализации, границы области обзора, масштаба осей, списка видимых величинЕсли это все, то проще хранить данные не в SQL.
Но вообще правильно говорит — сначала надо убедиться что проблема в принципе существует.
Дык эта, в кларионах ссдшки SLC от стека так что им вааще похер на количество записей потому как внутри кэш+батарейка+контроллер умный.
Если это все, то проще хранить данные не в SQL.А в чём?
А в чём?Я твою задачу точно не знаю.
Понятно что SQL придуман не для того чего ты от него сейчас хочешь, а для реляционной алгебры — в твоей задаче ее в общем нет.
Точно так же понятно что идея "экономить записи" странная и общее решение под нее оптимизировано не будет — любой движок будет стараться строить и перестраивать индексы, потому что обычно настроен на скорость (кстати, их можно отключить?).
Если у тебя 5 переменных и 3 уровня детализации, скажем, то можно взять 15 файлов и банально дописывать в них строчки с уже посчитанными значениями.
Поверх такой структуры делать нужные тебе запросы легко, вроде бы?
Дык эта, в кларионах ссдшки SLC от стека так что им вааще похер на количество записей потому как внутри кэш+батарейка+контроллер умный.небольшой writeback есть почти на всех ssd, и на плате стоят несколько конденсаторов чтоб успеть его экстренно скинуть.
Оставить комментарий
yroslavasako
Про MySQL у меня больше академических знаний, чем практических, может доброфорум поможет ответить на простой вопрос.Я собираюсь написать в программе логирование данных в MySQL таблицу(ы чтобы графики потом было проще строить и вообще. А запускать прога будет на ssd, где критичны циклы перезаписи. Поставить большой файловый кэш можно - соответсвенно логи будут падать большими кусками и не будут перезаписываться. Но вот индекс будет постоянно перезаписываться. Как можно разумно минимизировать этот эффект?