我认为您可以自己回答，所以我在这里的回答仅是为了推动您前进.

I think you are on to your own answer, so my response here is only intended to push you along.

nosql与传统sql数据库之间的主要区别是缺少查询计划.查询计划是sql数据库提供的功能，它在其中接受您的查询，对其进行解析，然后将其转换为查找匹配记录并将其返回给您的结果集中的算法.查询计划涉及选择***方法，通常是通过尽量减少所涉及的步骤数，所涉及的内存量或将要花费的时间量来进行.另一方面，您自己使用nosql.您必须成为通宵查询计划专家.

The main difference between nosql and a traditional sql database is the lack of query-planning. Query planning is the functionality provided by an sql database, where it accepts your query, parses it, and then converts it into an algorithm that finds matching records and returns them to you in a result set. Query planning involves choosing the most optimal approach, generally by trying to minimize the number of steps involved, the amount of memory involved, or the amount of time that will elapse. On the other hand, you are on your own with nosql. You have to become an overnight query-planning expert.

这既是福音，也是负担.对于某些人来说，查询计划是一个复杂性的悬崖，您可以很快发现自己正在阅读一些令人困惑的内容.但是，如果您正在寻找一个更技术性的答案，那么就会朝着这个方向发展，即了解有关数据库如何进行查询计划的更多信息.

That's both a boon and a burden. Query planning is a complexity cliff for some, and you can quickly find yourself reading some confusing stuff. But if you are looking for a more technical answer then it would be in this direction, of learning more about how databases do query planning.

为加快速度，我将应用有关归一化和非归一化的相同常规知识.博伊斯·科德(Boyce-Codd)和正常形式1-5等. nosql在极端非规范化方面.您存储的项目的逻辑"结构无关紧要.使用nosql，您的目标不是一个很好的传统直观的模式.您的目标是有效执行存储操作和查询.

To speed that up, I would apply the same conventional knowledge about normalization and denormalization. Boyce-Codd and normal forms 1-5 and all that. nosql is on the extreme denormalization end. The 'logical' structure of the items you store is irrelevant. With nosql your objective is not a nice traditional and intuitive schema. Your objective is to efficiently perform your storage operations, your queries.

因此，要回答这个问题，您必须先对操作进行简单分析.枚举您的应用程序执行的操作.哪些操作最频繁?您认为哪一个完成时间最长?通过操作，这里我不是在谈论低级查询，也不是在nosql/sql中谈论数据库的架构.那是一个太深的抽象层次.更抽象地思考.列举诸如为满足这些条件的所有人员加载信息"，删除那里的那些人"之类的内容.我选择了您提到的一些查询，但没有选择一个明确的列表，该列表是正确答案的重要条件.

So to answer the question you have to start with a simple analysis of your operations. Enumerate the operations your app performs. Which are the most frequent operations? Which do you assume will take the longest to complete? By operations, I am not talking about low level queries here, nor the schema of your db in nosql/sql. That is a level too deep of abstraction. Think more abstractly. Enumerate things like "load the info for all the people that meet these conditions", "delete those people over there". I picked up on some of the queries you mention, but I didn't pick up on a clear list, and this list is important criteria in a proper answer.

一旦您列举了这些操作，那么我认为您将更接近回答您的问题.作为一个玩具示例，请考虑更新.更新频繁吗?频繁的更新将表明一个对象存储是不好的，因为您必须加载大量不相关的东西才能更改一个对象的一个​​属性.考虑粒度.您是否需要对象的所有属性，或仅需要其中一些属性?想想最频繁的手术是什么?是否根据某些条件加载对象列表?它是删除还是更新内容?考虑一下在同一时间(同一位置)装载什么东西.当您加载一个2级对象的实例时，其他实例通常也被加载吗?如果没有，那么为什么将它们存放在一起?摆脱标准化的架构，而不必理会它.您需要一种非规范化的架构，在其中以某种方式存储数据以优化查询.最终结果可能与您想像的不一样.

Once you have enumerated those operations, then I think you are closer to answering your question. As a toy example, think about updates. Are updates frequent? Frequent updates would suggest one object store is bad, because you have to load a ton of irrelevant things just to change one property of an object. Think about granularity. Do you need all of an object's properties, or only some? Think about what is the most frequent operation? Is it loading a list of objects according to some criteria? Is it deleting or updating things? Think about what things are loaded at the same time (co-location). When you load one instance of a level 2 object, are the other instances typically also loaded? If not, then why store them together? Step away from your normalized schema and just forget about it. You want a denormalized schema where you are storing data in a manner so as to optimize your queries. The end result may be nothing like what you imagine.

也许是一个很好的想法实验.伪代码将执行实际的繁重的功能.您将直接遇到问题，并确定功能中可能真的很慢的部分.那么，对于您的问题的答案实际上就是什么数据结构可以真正加快这些部分的速度，或者至少比其他数据结构减速的速度更慢.

Maybe a good thought experiment would be this. Pseudocode the function that would do the actual heavy lifting. You will run straight into the problems and identify the parts of the function that will probably be really slow. The answer to your question then is essentially what data structure would really speed those parts up, or at least slow them down less than other data structures.

一个小小的跟进. Nosql数据库和反规范化的一个相当违反直觉的功能是，您可能最终会多次存储数据.有时将相同的数据存储在多个位置很有意义.因为它可以加快查询速度.是的，它引入了不一致的空间，并且违反了sql的no-function-dependencies规则.但是，您可以通过使用多商店事务和一些注意来强制执行数据完整性(一致性).为了进一步详细说明，您想要的存储可能只是您计划执行的查询的字面结果.是的.为您计划执行的每个查询创建一个对象存储.在所有数据之间冗余存储数据.是的，这听起来很疯狂而且极端.这有点夸张.但是，在使用nosql时，这种方法很常见，并且得到了推广.

one little followup. A rather counterintuitive feature of nosql databases and denormalization is that you may end up storing data multiple times. Sometimes it makes sense to store the same data in multiple places. Because it speeds up queries. And yes it introduces room for inconsistencies, and violates the no-functional-dependencies rule of sql. But you can enforce data integrity (consistency) through the use of multi-store transactions and a bit of care. To elaborate further, the stores you want might just be the literal results of the queries you plan to perform. Yes. Create an object store for each query you plan to perform. Store data redundantly among all of them. Yes that sounds nutty and extreme. And it is a tad exaggerated. But this approach is common, and promoted, when using nosql.

这是一个粗略的第一次尝试，只是集思广益，这是在猜测您实际要做什么的基础上给您一个更具体答案的尝试

and here is a rough first attempt, just brainstorming a bit, this is an attempt to give you a more concrete answer based on guessing what you are trying to actually do

您想要的是一个称为设置"的对象存储.存储中的每个对象都代表一个设置"对象.单个设置对象具有以下属性:设置ID，设置属性名称，设置属性值，1级属性，2级属性，3级属性.

What you want is an object store called 'settings'. Each object in the store represents a Settings object. A single settings object has the properties like settings id, settings property name, settings property value, level 1 property, level 2 property, level 3 property.

您的基本读取查询可能看起来像SELECT * from Settings WHERE level1 = 'a' && level2 = 'b'.

Your basic read queries might look like SELECT * from Settings WHERE level1 = 'a' && level2 = 'b'.

进一步，您可以使用索引针对某些视图进行优化.我们可以在level1属性上创建索引，在level2属性上创建索引，并在level1 + level2属性上创建索引.

Taking this further, you could then optimize for certain views, using indices. We could create an index on the level1 property, and index on the level2 property, and an index on the level1+level2 properties combined.

比方说，最频繁的操作(最快的操作)是加载属于级别1，级别2和级别3的特定组合的所有设置.在所有级别3上创建索引，然后就可以了.遍历该索引.

Let's say your most frequent operation, that needs to be fastest, is to load all settings belonging to a particular combination of levels 1, 2, and 3. Create an index on all 3, and then it is just a matter of iterating over that index.

此集思广益示例中的模式是单个对象存储，以及一些索引以加快某些查询的速度.鉴于索引基本上是派生的对象存储，尽管实际上您实际上只使用一个存储，但您实际上可以使用多个存储作为概念上的参数.无论如何，可能会变得很书呆子.该示例的目的只是说明对象存储库的架构与如何概念化投资组合和级别的层次完全无关.它只与使您需要快速执行的查询有关.

The schema in this brainstorming example is a single object store, along with some indices to speed certain queries up. Given that indices are basically derived object stores, you could make the conceptual argument you are practically using multiple stores although you are actually only using one. Anyway that might be getting pedantic. The point of this example is just to demonstrate that the schema of your object store has nothing at all to do with how you conceptualize the hierarchy of portfolios and levels. It only has to do with making the queries you need to perform fast.