DuckDB

在关系型数据库中，INSERT语句是将数据加载到数据库的常用方法。使用INSERT语句时，数据是按行逐个插入的。虽然这种方式直观易懂，但在解析和处理每一个单独的INSERT语句时会涉及到较大的开销。这导致当进行大量数据的批量插入时，逐行插入变得非常低效。

最佳实践
避免频繁的逐行插入：作为一般规则，当插入多于几行的数据时，应避免使用大量的逐行INSERT语句（即不要在循环中使用INSERT语句）。在进行大批量数据插入时，应尽量增加每次语句插入的数据量。
避免自动提交模式：如果你必须在循环中使用INSERT语句来加载数据，请避免在自动提交模式下执行这些语句。在自动提交模式下，每个单独的语句都会被包裹在一个独立的事务中，意味着每次提交后数据库都需要将更改同步到磁盘以确保数据不丢失。在批量加载数据时，这种同步通常是不必要的，并且会显著减慢程序的速度。
小贴士
使用事务来包裹循环中的INSERT语句：如果你必须在循环中使用INSERT语句加载数据，可以将这些语句包裹在BEGIN TRANSACTION和COMMIT语句之间，这样可以将多次插入操作合并到一个事务中，减少磁盘同步的频率，从而提高数据加载速度。
通过使用上述的最佳实践和技巧，可以有效地优化数据库的数据加载过程，特别是在处理大批量数据时，可以显著提升性能和效率。

缺点:

嵌入式DB，只允许一个程序读和写,或者多个程序写

CLickhouse

ClickHouse作为一种在线分析处理（OLAP）数据库，其设计和优化重点在于高性能和可扩展性，能够支持每秒插入数百万行数据。这一能力的实现基于高度并行化的架构、列式存储带来的高压缩比，但同时也牺牲了一定程度的一致性。具体来说，ClickHouse为追加操作进行了优化，仅提供最终一致性保证。

相比之下，像PostgreSQL这样的在线交易处理（OLTP）数据库，专门针对事务性的插入操作进行了优化，确保遵循ACID原则，即原子性、一致性、隔离性和持久性，以提供强大的一致性和可靠性保障。PostgreSQL采用多版本并发控制（MVCC）技术来管理并发事务，这涉及维护数据的多个版本。事务处理可能涉及少量行数据，但由于可靠性保障带来的开销限制了插入性能。

为了在ClickHouse中实现高插入性能同时保持强一致性保证，用户应遵循以下简化的规则：

批量插入：尽量将插入操作组织为批量操作，而非单行插入。这利用了ClickHouse的并行处理能力，减少了元数据操作的开销，提高了整体的插入效率。
使用适当的插入格式：ClickHouse支持多种数据插入格式，如TabSeparated、CSV等。选择一种适合数据特性和性能要求的格式可以进一步优化插入过程。
避免频繁的小事务：ClickHouse不是为频繁的更新和删除操作设计的。尽量减少这类操作，特别是小规模的更新和删除，因为它们可能导致数据碎片化，降低性能。
定期优化表结构：定期执行表的优化操作，如OPTIMIZE TABLE，可以帮助整理数据，减少存储开销，提高查询性能。
利用分区和索引：合理设置分区和索引策略，可以加速查询和插入过程，尤其是在数据量大时。

通过遵循这些规则，用户可以充分利用ClickHouse的优势，同时避免在初次使用时可能遇到的一些常见问题，尤其是试图复制传统OLTP数据库插入策略时可能出现的问题。这样不仅能够提升插入性能，还能确保数据的一致性和系统的稳定性。

CLickHouse VS ProstgreSQL VS TimescaleDB

在高层次上，ClickHouse是一个为分析系统设计的优秀的OLAP数据库。

相比之下，PostgreSQL是一个通用的数据库，它被设计成一个通用的、可靠的OLTP数据库，用于具有高用户参与度的记录系统。

TimescaleDB是一个用于时间序列的关系数据库:专门在PostgreSQL上构建，用于时间序列工作负载。它结合了PostgreSQL的优点和提高性能、降低成本的新功能，并为时间序列提供了更好的开发体验。

所以，如果你发现自己需要对大多数不可变的大型数据集和少数用户执行快速分析查询，例如OLAP, ClickHouse可能是更好的选择。

相反，如果你发现自己需要一些更通用的东西，可以很好地支持具有许多用户和可能频繁更新/删除的应用程序，例如OLTP, PostgreSQL可能是更好的选择。

如果你的应用程序有时间序列数据，特别是如果你还想要postgresql的多功能性，timescaledb可能是最好的选择。

Feast

TL,DR: 特征存储通常是存储已经被处理过的特征(表征)了
输入图片说明

输入图片说明
Feast用项目组织特征,不同项目的特征是独立的,无法同时检索不同项目的特征,每个项目的特征分成了多个视图,每个视图由三个部分定义:特征,实体和数据源,一个项目包含多个视图,一个视图包含多个实体,特征与其中的实体相关,一个视图包含一个数据源

Feast are not:

数据仓库:Feast不是数据仓库的替代品，也不是组织中所有已转换数据的真实来源。相反，Feast是一个轻量级的下游层，可以将来自现有数据仓库(或其他数据源)的数据提供给生产中的模型。

数据库:Feast不是一个数据库，但它可以帮助管理存储在其他系统(例如BigQuery, Snowflake, DynamoDB, Redis)中的数据，以使功能在训练/服务时始终可用

Who is Feast for?

Feast帮助具有DevOps经验的ML平台团队将实时模型产品化。Feast还可以帮助这些团队建立一个功能平台，以改善工程师和数据科学家之间的协作。

如果您需要，Feast可能不是合适的工具:

你所在的组织刚刚开始使用机器学习，还不确定机器学习的业务影响是什么
主要依赖非结构化数据
需要非常低的延迟特征检索(例如p99特征检索<< 10ms)
有一个小团队来支持大量的用例吗

特征预计算（Feature Precomputation）

机器学习和深度学习中的一种优化策略，特别是在处理大规模数据集或复杂模型时。其核心思想是在训练模型之前，预先计算出一些复杂的特征表示，然后将这些预计算的特征作为模型的输入，从而加速模型训练和预测的过程，或者简化模型的复杂度。

在深度学习中，特征预计算常常与卷积神经网络（CNNs）或自编码器（Autoencoders）等预训练模型结合使用。例如，可以使用一个预训练的CNN来提取图像的特征，然后将这些特征保存下来，作为后续模型的输入。这样做的好处是：

加速训练：预训练模型通常在大型数据集上训练过，能够捕获数据的高级抽象特征。使用这些预计算特征可以减少训练新模型时的计算负担，因为不需要从头开始学习基础特征。
降低维度：预计算特征通常会将原始数据的维度降低到一个更易于管理的大小，这有助于减少过拟合风险，并加快训练过程。
提高泛化能力：预训练模型往往具有良好的泛化能力，使用其提取的特征可以增强下游模型的性能。
特征重用：一旦特征被预计算，它们可以在不同的模型和任务中重复使用，避免了重复的计算工作。
模型简化：预计算特征可以简化模型架构，有时甚至可以使用线性模型或较简单的模型来达到满意的性能。