背景
我们有一个以100赫兹接收传感器数据的应用程序。每个传感器数据包含三个浮点数。偶尔（最大1 / s）可能会收到一些其他需要保存的元数据。 UI在图形中显示最新的1000个传感器值。没有撤消要求 - 所有收到的数据都必须保存到文件中。每个会话持续至少10分钟，但可能（在极少数情况下，主要是由于错误）长达一个小时。
当前方法
模型： SensorData与Session有多对一的关系。 MetaData与Session有多对一的关系。
CoreData：设置UIManagedDocument来处理CoreData。主线程上有一个MOC，私有队列上有子MOC。子MOC创建对象并将它们添加到对象图中。每100个数据，保存儿童MOC。会话结束后，将主MOC保存到PSC。
编辑：我对当前方法的问题是，子MOC中的保存滞后，这意味着当会话结束并且处理时间随着运行时间的增加而没有处理完所有数据。 / p>
问题
答案 0 :(得分：1)
我认为Core Data可以做到这一点。
你可以使用Marcus Zarra的三种情境来确保实际的保存也发生在后台。
RootContext (background) saves to persistent store ---> is parent of
MainContext (main thread) to update the UI ---> is parent of one or more
WorkerContext (background) to create new data from sensor
然后，您可以直接在后台更频繁地保存到持久性存储，而不会影响UI响应。这也应该提高内存使用率。保存工作线程上下文会将更改推送到可以相应更新的UI。
对于性能，请确保批量保存 - 使用三个浮点数，我估计每1000到5.000个记录左右（您需要尝试找到最佳值）。
关闭撤消管理器。 （context.undoManager = nil）
另一个考虑因素可能是想要想要在UI中显示什么并且可能计算要在运行中显示的值并将其发送到UI，而不是让UI依赖整个会话的数据集来更新本身。
答案 1 :(得分：1)
我在this project的详细阐述中反对这个问题。
我的任务是以高达100Hz的速率记录来自（例如）Core Motion和Core Location的实时传感器数据，同时运行一个平滑的动画界面，可以插入任何Core Graphics，Core Animation，OpenGL和实时视频。有大约20-40个单独的数据项需要跟踪，大多数是双倍但只有一个或两个字符串，并且它们并非都达到相同的同步速率。
保存期间的任何保持，无论多么轻微，都会立即触发界面。
我有兴趣比较使用Core Data直接写入SQL数据库（使用sqlite3）。到目前为止，我的个人经验（这是一项正在进行的工作）是SQL方法比Core数据更适合这类问题。事实上，它并不是Core Data优化的（而是管理具有撤消，持久性和高效错误的复杂文档对象模型）。核心数据模型几乎假设持久保存将非常缓慢（例如，保存到iCloud），并且其中许多工程旨在为提供的解决方案问题。
我尝试了各种核心数据模式，后台处理，父/子上下文，同步，异步，批处理保存......并且每当实际发生持久保存时，我总会发现明显的口吃。
另一方面，SQL方法易于理解，高效且完全没有明显的故障。
很可能我没有达到这个问题的最佳核心数据模式（我将深入研究这个问题，因为它是一个有趣的边缘情况）。但是，如果在更广泛的应用程序环境中对您有意义，我肯定会建议您查看直接到SQL的方法。
在稍微不同的数据流用例中（例如，通过蓝牙传送250-500Hz信号）我选择了音频接口使用的那种信号处理技巧 - 环形缓冲区 ，随着数据速率的提高，队列和回调变得非常有用。在某些时候，数据速率将变得太高，数据库写入过程无法跟上：然后 - 正如您所建议的那样 - 直接保存到文件将更有效。您可以随时在文件中读取数据，并在未进行采样时填充数据库（或核心数据）。
Matt Gallagher对核心数据和数据库做了很好的比较。 It's a fairly old piece, but the patterns haven't changed so it is still relevant。关于平面文件优于使用高频流进行数据库写入的好处，也很有用（和类似年龄）讨论here。