#c #linux #string #casting #int
#c #linux #строка #Кастинг #int
Вопрос:
Я читаю несколько файлов из linux / proc fs, и мне нужно будет вставить эти значения в базу данных. Я должен быть максимально оптимальным. Так что же дешевле:
i) затем преобразовать в int, пока я сохраняю then в памяти, для последующего преобразования в string снова, пока я создаю свой оператор INSERT
ii) или сохранить их в виде строки, просто очистив значения (удалив ‘:’, пробелы и т.д.)
iii) Что я должен принять во внимание, чтобы научиться принимать это решение?
Я уже делаю разделение строк, потому что порядок, в котором они пришли, недостаточно хорош для меня.
Спасибо,
Педро
Редактировать — уточнение
Извините, ребята, мой сценарий следующий: я измеряю процессор, память, сеть, диск и т.д. каждые 10 секунд. Мы разрабатываем нашу систему баз данных, поэтому я не могу рассчитывать ни на что большее, чем просто инструкции INSERT.
Я заинтересовался этой оптимизацией, потому что снизил частоту синтаксического анализа данных. Это будет запись один раз — после записи данных обновлений не будет.
Комментарии:
1. Оптимально в каком смысле? С точки зрения хранения или производительности?
2. Лучше всего сначала заставить его работать, а затем провести сравнительную разметку, чтобы увидеть, где находятся узкие места.
3. Многие API баз данных поддерживают подготовленные инструкции / запросы, которые автоматически очищают значения в соответствии с серверной частью базы данных. Почему вы очищаете вручную?
4. Преждевременная оптимизация. Все, что вы делаете, будет незначительным по сравнению со стоимостью вставки в БД. Таким образом, сделайте on, который облегчает чтение кода (что, на мой взгляд, означает хранение целочисленных значений в целочисленных объектах).
5. Спасибо, ребята, я делаю так, как сказал GWW: закончу первым, а не бенчмарком. Я просто пишу разъяснение для вас, я предполагаю, что мой сценарий был недостаточно ясен.
Ответ №1:
Похоже, вы выполняете какое-то архивирование [запись-один раз, чтение-вероятно-самое большее-один раз] (сохраняете базу данных для последующего редкого / нечастого использования), если нет, вам следует сделать акцент на оптимизации, основываясь на том, как данные будут считываться (не записываться).
Если это случай архивирования, возможно, вставка больших двоичных объектов (двоичных больших объектов [или аналогичных концепций]) в БД будет более эффективной.
Дополнение: По-видимому, это будет зависеть от того, как вы будете считывать данные. Вы просто перечисляете данные для последующего просмотра, или будут более сложные запросы на выборку на основе эталонных значений. Например, если вы позже выполняете что-то вроде: SELECT * from db.Log WHERE log.time > time1 and Max (Memory) < 5000 тогда лучше всего сохранить все данные в их исходном формате (int в integer, string в String и т.д.), Чтобы основная обработка данных была возложена на сервер БД.
Комментарии:
1. «акцент на оптимизации, основанный на том, как будут считываться данные», именно, это моя фишка, и в этом мой вопрос. Сохранить строку или преобразовать в int, отключив поток, о котором сказал Локи Астари: «Таким образом, сделайте on, чтобы код было легче читать»
2. @PedroDusso ну, это зависит от типа использования данных и выборки (подробнее читайте в конце ответа выше [прилагается])