一、为什么Elixir应用需要持久化？
在Elixir的世界里，进程是王者。它们轻巧、快速，在内存中处理着海量的并发任务。但内存有个“坏毛病”——一旦应用重启或者服务器断电，里面的数据就全没了。想象一下，你正在玩一个在线游戏，角色升级、获得装备的数据如果只存在内存里，服务器一维护，你就得从头再来，这肯定无法接受。所以，我们需要“持久化”——就是把数据从易失的内存，搬到更稳定的存储介质（比如硬盘）里，让它们能够长久保存。
Elixir本身不直接提供数据库，但它给了我们几种非常强大的工具，让我们可以根据不同的需求来选择如何保存数据。今天，我们就来聊聊其中最常用的三位“选手”：ETS、Mnesia和PostgreSQL。它们各有各的绝活，用对了场景，事半功倍；用错了，可能就是一场灾难。
二、内存中的闪电侠：ETS
ETS，全称是“Erlang Term Storage”，你可以把它理解成Elixir/Erlang虚拟机内部的一个超级快的“键值对”大表格。它完全驻留在内存里，访问速度堪比直接读取变量。
技术栈：Elixir/OTP
优点：
- 速度极快：因为是内存操作，读写都是纳秒到微秒级别。
- 使用简单：接口直观，和操作Map很像。
- 进程共享：ETS表可以被同一个虚拟机内的所有进程访问，是进程间共享数据的利器。
缺点：
- 数据易失：ETS默认是存储在内存的，虚拟机停止，数据就丢失。虽然可以设置成“磁盘表”，但那是为了容错，性能会下降，并非设计初衷。
- 查询能力有限：主要支持基于键的精确查找，虽然也支持模式匹配，但复杂查询远不如SQL方便。
- 容量受限：受限于服务器内存大小。
适用场景：
- 缓存：缓存数据库查询结果、渲染的页面片段等。
- 计数器和统计：实时在线人数、API调用次数。
- 进程注册表：快速查找某个进程的PID。
- 临时共享状态：多个进程需要共同维护和快速访问的一份数据。
示例：用ETS实现一个简单的API调用频率限制器
# 技术栈：Elixir/OTP
defmodule RateLimiter do
# 创建一个名为 `:api_calls` 的ETS集合表（键唯一）
# `:public` 表示所有进程可读写
# `:named_table` 允许我们通过名字访问它
@ets_table :api_calls
def setup do
# 启动时创建ETS表
:ets.new(@ets_table, [:set, :public, :named_table, {:write_concurrency, true}])
end
def check_and_update(user_id, limit, window_ms) do
current_time = System.monotonic_time(:millisecond)
key = {user_id, current_time}
# 1. 插入当前这次调用记录，键是 {用户ID, 当前时间戳}
:ets.insert(@ets_table, {key})
# 2. 计算时间窗口的起始点
window_start = current_time - window_ms
# 3. 使用匹配规范（match spec）来查询这个用户在时间窗口内的所有调用
# 这是一个比简单键查找更高级的用法，但ETS依然能高效处理
match_spec = [
# 匹配所有键为 `{^user_id, timestamp}` 的记录
{{:"$1", :"$2"}, [{:andalso, {:==, :"$1", user_id}, {:>, :"$2", window_start}}], [:"$2"]}
]
calls_in_window = :ets.select(@ets_table, match_spec)
# 4. 判断是否超限
if length(calls_in_window) > limit do
# 超限，删除刚才插入的本次记录（可选，保持数据干净）
:ets.delete(@ets_table, key)
{:error, :rate_limit_exceeded}
else
{:ok, :allowed}
end
end
def cleanup_old_entries(window_ms) do
# 定期清理过期数据的任务
cutoff_time = System.monotonic_time(:millisecond) - window_ms
match_spec_for_delete = [{{:"$1", :"$2"}, [{:<, :"$2", cutoff_time}], [true]}]
:ets.select_delete(@ets_table, match_spec_for_delete)
end
end
# 使用示例
# RateLimiter.setup()
# 检查用户123在最近60秒内是否超过10次调用
# result = RateLimiter.check_and_update(123, 10, 60_000)
注意事项：
ETS表有类型（:set, :ordered_set, :bag, :duplicate_bag），创建时要根据需求选对。对于高并发写入，记得使用 write_concurrency: true 选项。它不是数据库，别用它存需要永久保存的核心业务数据。
三、内嵌的分布式能手：Mnesia
Mnesia是OTP自带的一个分布式数据库管理系统。它很特别，数据既可以放在内存（像ETS一样快），也可以放在磁盘（持久化），甚至可以在同一个表中混合存储。它最大的招牌功能是分布式，可以轻松地在多个Erlang节点间同步数据。
技术栈：Elixir/OTP
优点：
- 与Elixir/Erlang无缝集成：数据直接就是Elixir的Term，无需转换。
- 灵活的存储：可配表为内存、磁盘或两者兼有。
- 事务支持：提供了事务操作，保证复杂数据变更的一致性。
- 分布式原生：通过配置，可以让数据在集群节点间自动复制和分发，实现高可用。
缺点：
- 查询能力依然较弱：虽然提供了QLC（查询列表推导）进行复杂查询，但语法和功能相比SQL仍显晦涩和有限。
- 运维和扩展性：当数据量巨大或集群规模很大时，运维复杂度高于传统数据库。不适合需要复杂分析、关联查询的场景。
- 社区和工具生态：不如主流SQL或NoSQL数据库丰富。
适用场景：
- 分布式配置/状态存储：在微服务集群或分布式系统中，存储需要全局一致的配置信息、会话状态。
- 电信或即时通讯领域：存储用户在线状态、路由信息等，利用Erlang生态的软实时和分布式优势。
- 需要事务的缓存或暂存层：数据比ETS更需要持久化和一致性保证，但又不想到外部数据库绕一圈。
示例：用Mnesia管理一个简单的分布式用户会话存储
# 技术栈：Elixir/OTP
defmodule DistributedSessionStore do
@session_table :user_sessions
def init_db do
# 停止Mnesia（如果正在运行）
:mnesia.stop()
# 创建数据库模式（Schema），并复制到当前节点
:mnesia.create_schema([node()])
# 启动Mnesia
:mnesia.start()
# 定义表结构：表名、属性列表（类似字段）、选项
table_definition = [
# 属性：id, user_id, session_data, expires_at
attributes: [:id, :user_id, :session_data, :expires_at],
# 磁盘副本位于当前节点（数据会持久化到磁盘）
disc_copies: [node()],
# 类型是集合（键唯一）
type: :set
]
# 创建表
case :mnesia.create_table(@session_table, table_definition) do
{:atomic, :ok} -> IO.puts("Table #{@session_table} created.")
{:aborted, {:already_exists, _}} -> IO.puts("Table already exists.")
error -> IO.puts("Error creating table: #{inspect(error)}")
end
end
def create_session(user_id, data, ttl_seconds) do
# 在事务内执行写入操作，保证原子性
:mnesia.transaction(fn ->
id = System.unique_integer([:positive])
expires_at = System.system_time(:second) + ttl_seconds
session_record = {@session_table, id, user_id, data, expires_at}
:mnesia.write(session_record)
id # 返回会话ID
end)
end
def get_valid_session(session_id) do
# 在事务内执行读取操作
{:atomic, result} = :mnesia.transaction(fn ->
now = System.system_time(:second)
# 使用:match_object进行模式匹配查询
match_head = {@session_table, session_id, :"$1", :"$2", :"$3"}
guard = [{:>, :"$3", now}] # 确保未过期
result = :mnesia.select(@session_table, [{match_head, guard, [:"$1", :"$2"]}])
List.first(result) # 返回 [user_id, session_data] 或 nil
end)
result
end
# 假设我们在另一个节点上也启动了Mnesia并加入了模式
# 我们可以修改表定义，添加 `ram_copies: [Node.self(), :other_node@host]`
# 这样表就会在多个节点上有内存副本，实现分布式读取和容错。
end
# 使用示例
# DistributedSessionStore.init_db()
# {:atomic, session_id} = DistributedSessionStore.create_session(1001, %{theme: "dark"}, 3600)
# user_data = DistributedSessionStore.get_valid_session(session_id)
注意事项：
Mnesia的配置，尤其是分布式配置，需要仔细设计。表类型（ram_copies, disc_copies, disc_only_copies）的选择直接影响性能和持久化能力。对于生产环境，一定要有清晰的数据备份和迁移方案。
四、成熟稳健的外援：PostgreSQL
PostgreSQL是一个功能极其强大的开源关系型数据库。在Elixir中，我们通常通过Ecto这个绝佳的数据库封装库来与它交互。Ecto提供了数据映射、验证、查询构建和迁移等功能，让操作SQL数据库变得优雅而安全。
技术栈：Elixir + Ecto + PostgreSQL
优点：
- 功能全面：支持标准的SQL、ACID事务、复杂查询、关联、聚合、索引等。
- 数据安全与持久化：专为安全持久化设计，可靠性极高。
- 强大的生态系统：有海量的工具、客户端、管理界面和云服务支持。
- 扩展性强：数据量增长后，可以通过分库分表、读写分离等方式扩展。PostgreSQL本身也支持JSONB等非结构化数据。
缺点：
- 速度相对较慢：相比内存操作，磁盘I/O和SQL解析带来了开销，延迟在毫秒级。
- 复杂性：需要单独部署、维护、备份和优化。引入了外部依赖。
- 对象-关系阻抗不匹配：需要用Ecto在Elixir数据结构和数据库表之间进行映射和转换。
适用场景：
- 核心业务数据：用户账户、订单、商品信息等需要绝对持久化和复杂查询的数据。
- 需要复杂报表和分析的应用。
- 已有PostgreSQL基础设施的团队。
- 需要严格关系模型和事务保证的任何场景。
示例：使用Ecto定义模式、迁移和操作PostgreSQL
首先，我们需要在mix.exs中添加依赖，并配置config/dev.exs中的数据库连接，这里假设已经完成。
# 技术栈：Elixir + Ecto + PostgreSQL
# 1. 定义上下文和模式（Schema） - 在 lib/my_app/accounts/user.ex
defmodule MyApp.Accounts.User do
use Ecto.Schema
import Ecto.Changeset
schema "users" do
field :email, :string
field :name, :string
field :age, :integer
field :preferences, :map # 使用PostgreSQL的JSONB类型存储
timestamps() # 自动添加 inserted_at 和 updated_at
end
@doc false
def changeset(user, attrs) do
user
|> cast(attrs, [:email, :name, :age, :preferences])
|> validate_required([:email, :name])
|> validate_format(:email, ~r/@/)
|> validate_number(:age, greater_than_or_equal_to: 0)
|> unique_constraint(:email) # 在数据库层面保证邮箱唯一
end
end
# 2. 创建数据库迁移文件 - 在 priv/repo/migrations/20230000000000_create_users.exs
defmodule MyApp.Repo.Migrations.CreateUsers do
use Ecto.Migration
def change do
create table(:users) do
add :email, :string, null: false
add :name, :string, null: false
add :age, :integer
add :preferences, :map # 在PostgreSQL中对应JSONB类型
timestamps()
end
# 为email字段创建唯一索引，加速查找并保证唯一性
create unique_index(:users, [:email])
# 可以为name或age创建普通索引以优化查询
# create index(:users, [:name])
end
end
# 3. 在业务逻辑中使用 - 在 lib/my_app/accounts.ex
defmodule MyApp.Accounts do
import Ecto.Query
alias MyApp.Repo
alias MyApp.Accounts.User
def create_user(attrs) do
%User{}
|> User.changeset(attrs)
|> Repo.insert()
# 返回 {:ok, %User{}} 或 {:error, %Ecto.Changeset{}}
end
def get_user_by_email(email) do
Repo.get_by(User, email: email)
end
def get_users_over_age(age_limit) do
# 使用Ecto查询语法，清晰易读
query = from u in User,
where: u.age >= ^age_limit,
order_by: [desc: u.age],
select: {u.name, u.email}
Repo.all(query)
end
def update_user_preferences(user_id, new_prefs) do
# 在事务中执行复杂更新
Repo.transaction(fn ->
user = Repo.get!(User, user_id)
# 深度合并偏好设置
updated_prefs = Map.merge(user.preferences || %{}, new_prefs)
changeset = User.changeset(user, %{preferences: updated_prefs})
case Repo.update(changeset) do
{:ok, user} -> user
{:error, changeset} -> Repo.rollback(changeset.errors)
end
end)
end
end
# 使用示例（通常在IEx中或控制器中调用）
# MyApp.Accounts.create_user(%{email: "alice@example.com", name: "Alice", age: 30, preferences: %{theme: "dark", language: "en"}})
# user = MyApp.Accounts.get_user_by_email("alice@example.com")
# adults = MyApp.Accounts.get_users_over_age(18)
# {:ok, updated_user} = MyApp.Accounts.update_user_preferences(user.id, %{notifications: false})
注意事项： 务必正确设计数据库模式、索引和约束。利用Ecto Changeset做好数据验证和清洗。对于复杂应用，合理规划上下文和领域边界。PostgreSQL的性能优化是一个专业领域，涉及查询分析、索引优化、连接池配置等。
五、如何选择？场景、优缺点与总结
看到这里，你可能已经有点感觉了。选择哪种持久化策略，根本上是回答以下几个问题：
- 数据需要存多久？ 临时缓存还是永久保存？
- 速度要求多高？ 微秒级响应还是毫秒级可接受？
- 数据量和结构如何？ 是简单的键值对，还是复杂的关联关系？
- 需要事务和强一致性吗？
- 系统是分布式的吗？ 数据需要在多个节点间同步吗？
- 团队运维能力如何？ 能否维护一个外部数据库？
让我们再清晰地对比一下：
- ETS：你的“内存工作台”。处理临时、高速的访问需求。优点是极致的快和简单；缺点是易失、功能单一。记住：它不是你系统的“保险柜”。
- Mnesia：你的“分布式工具箱”。当你的Elixir应用本身是集群，且需要节点间共享一份带点持久化和事务要求的状态时，它是非常内聚的选择。优点是分布式原生、与语言集成；缺点是查询弱、大数据量运维难。记住：它适合Erlang/Elixir生态内的特定分布式场景，不是通用数据库。
- PostgreSQL（通过Ecto）：你的“中央档案库”。存储你业务中所有重要、复杂、需要可靠保存和灵活查询的数据。优点是功能强大、可靠、生态好；缺点是速度相对慢、引入外部依赖。记住：对于大多数Web应用和业务系统，它都是核心数据的默认选择。
在实际项目中，它们常常是协同工作的。一个典型的架构可能是：
- 用 PostgreSQL 存储用户、订单等核心持久化数据。
- 用 ETS 缓存热门的PostgreSQL查询结果，或者存储当前活跃的进程ID列表。
- 用 Mnesia 在分布式节点间同步一个全局的配置开关或锁状态。
总结一下：没有最好的，只有最合适的。ETS为速度而生，Mnesia为分布式而生，PostgreSQL为持久化与复杂关系而生。理解它们的本质和边界，在你的Elixir架构中让它们各司其职，你就能构建出既快又稳、还能横向扩展的强大系统。下次当你需要保存数据时，不妨先停下来，问问自己：“这份数据，到底需要什么？” 答案自然会指向正确的工具。
评论