问题标签 [sql-azure-federations]

我们这里有一个有趣的情况。我们将存储库模式与 Entity Framework 一起使用，因此每个数据库表都有自己的 Repository 类，该类在其构造函数中接受 DbContext 的实例。我们还使用 Ninject 进行依赖注入。我们已经定义了在给定请求期间要实例化的单个上下文，以便当多个存储库请求 DbContext 时，始终使用相同的实例。这允许我们遵循 UnitOfWork 模式，因此可以在多个存储库上发生多件事，并且一次提交将提交所有更改到数据库。

这就是问题所在，我们还使用 SQL Azure Federations，它将我们的客户端数据拆分为多个数据库（分片）。我们需要能够在同一个请求中从一个联合成员（数据库）跳转到另一个，但希望能够使用依赖于注入上下文的相同服务/存储库方法。我们的第一个想法是仅在现有上下文上执行 USE FEDERATION sql 命令以移动到下一个数据库，但它似乎有时有效，而其他情况则无效。执行该语句后，我们看到上下文上的底层连接确实指向新服务器，但由于某种原因，在该上下文上执行的查询最终会返回前一个连接的结果。我认为在多个数据库上使用相同的上下文实例并不是真正原生支持的，因为您通常会在连接到新数据库时启动新上下文。不幸的是，我们有一堆使用 Ninject 动态创建的存储库，然后它们接收相同的上下文实例，因此即使我们确实为新数据库启动了一个新上下文，我们也无法让所有现有的存储库突然变成取决于我们刚刚启动的新上下文，而不是在初始请求中创建的上下文。

以下是我们可以想到的一些解决方案，但不确定如何使它们中的任何一个起作用：

1. 更改在现有上下文中使用的数据库（如上所述，但似乎不起作用）
2. 将所有存储库的注入上下文替换为新的，以便所有现有存储库现在都依赖于不同的上下文
3. 以某种方式从 Ninject 请求所有存储库的新实例，该实例在请求时传递上下文所需的参数。

同样，这里的底线是我们有一组依赖于单个上下文的存储库和服务，我们希望能够重用这些服务和存储库，但交换或更改所有依赖的上下文，以指向一个新的服务器。

我正在尝试在联合中更新我的 azure table1 的 Some 2500-3000 行。来自存储在联邦外部的 table2，在同一个 DB 中。

当我在本地运行我的工作角色时，我在 azure-emulator 中收到以下错误：

其次是 ：

这里发生了什么事 ？

当我尝试在联邦中创建表时出现此错误。我该如何解决这个问题。我必须使用身份。所有东西都设置好了。但是当尝试应用联邦时，就会发生这种情况。

提前致谢。

Question:

For a multi-tenant single-shared database -- should the tenantid field be included in the primary key (this would create a composite key for the applied table) and then the clustered index, or can the tenantid just be included in the clustered index and not be part of the primary key -- to support future azure federation possibilities?

---

Context/Background:

I prefer not to make the federated (tenantid) part of the primary key, because I will be making use of EF5 (or even released versions) and OData with Web API, and it is my understanding that working within EF and OData libraries will become more difficult with composite keys

I do not explicitly read where I need to make the federated key part of the primary key -- only composite key

I will not have to federate to start, but if I need to scale, I would like the option.

Note, I'm going to use GUIDs only because federation will not accept Identity column as Primary keys (another long topic, that is not relevant to this question)

---

Example:

Table: Tenant Primary Key(s): TenantID (GUID) Clustered Index: TenantID

With:

Table: Customer Primary Key(s): CustomerID (GUID) Foreign Key(s): TenantID (GUID) Clustered Index: Customer, TenantID

Or:

Table: Customer Primary Key(s): Customer, Tenant (Composite Primary Key) (GUIDs) Foreign Key(s): TenantID (GUID) Clustered Index: Customer, TenantID

---

Reference:

The following is an excerpt from Windows Azure Federation Guidelines and Limitations...

Federated tables have the following limitations: The federation column of the federated table can only contain data that confirms to the federation member range_low inclusive and range_high exclusive.

The data type of the federation column must exactly match the data type that is defined in the federation definition.

All unique and clustered indexes on the federated table must contain the federation column. The order in which the federation column appears in the index can be different from the key ordinal in the federation.

Federation column values cannot be updated to values outside the federation member range.

The federation column cannot be a persisted or non-persisted computed column.

Indexed Views are not supported in federation members.

Federation columns cannot be NULLable.

All foreign key constraints on federated tables need to include the federation column on both the referrer and the referenced tables at the same ordinal in the foreign key. Reference tables cannot have foreign key relationships with federated tables. Federated tables can have foreign key relationships with reference tables without restrictions.

You can drop tables created with the FEDERATED ON clause normally. You can also use ALTER TABLE to change all properties of a federated table except federation attributes such as the federation key. To change a reference table into a federated table or a federated table into a reference table, you must create new tables with the desired properties and drop the existing table.

When a table is marked with STATISTICS_NORECOMPUTE, federation operations like SPLIT do not invalidate or recalculate statistics. This could cause execution plan issues after re-partitioning operations such as SPLIT.

Federated members do not support the identity property

Federated members do not support the timestamp and rowversion data type.

我想使用 PEAR MDB2 sqlsrv 驱动程序连接 windows sql azure 数据库。

我可以使用这个连接非联合数据库

sqlsrv://username@server:password@server.database.windows.net:1433/mydatabase

但是对于联合数据库，我需要设置

"MultipleActiveResultSets" => 假

这也与连接字符串..

我怎样才能通过这个额外的参数..请帮助我

---

sqlsrv://username@server:password@server.database.windows.net:1433/mydatabase?op‌​tions="MultipleActiveResultSets=false"

这是发送额外值的正确方法吗？

I have to design a database for customer with email id as login but since we have lots of data we need to use federation but since we cant have string or varchar or nvarchar as federation key I am stuck at what should I do. User will use email id to login. How can I solve this problem? Please help me.

我们目前有一个 SQL 联合数据库，将数据分成大致相等的 10 个分片，并按客户端 ID 过滤。

目前我们在执行过滤查询时遇到性能问题，例如，为特定客户端运行查询可能需要 3 分钟以上才能在某些分片中返回 4000 行。但是，在同一分片上的未过滤连接中运行完全相同的查询会在 4 秒内及时返回。一个值得注意的方面是，经历减速的分片往往包含更多的客户端，尽管数据更少。最可能的性能抑制因素（我相信）将是索引以及与过滤/未过滤连接相关的东西。

搜索了一下，我没有找到太多关于跨分片的查询性能/分片上的特定索引策略的信息（除了 Azure 显然不支持索引视图）。我的印象（因此需要澄清）是索引应用于分片的所有成员，而不是逐个成员。

如果是前者，那么我们就有点麻烦了，除了重新分片这个没有意义的特定分片，考虑到唯一的区别是客户端的数量，而不是数据的大小。我们将要尝试的几件事是将过滤器显式添加到索引中，甚至将过滤器添加到每个查询中。可以肯定地说，我们不乐意离开过滤连接。

有没有其他人遇到过这个问题，或者可能提供一些方向来表明未过滤的连接明显优于过滤的连接？

提前致谢...

SQL Azure（Web 和商业）最多允许 180 个并发连接，如下所示：

http://blogs.technet.com/b/dataplatforminsider/archive/2013/07/23/premium-preview-for-windows-azure-sql-database-now-live.aspx

我试图理解并发连接的含义。

假设有一个使用 SqlConnection 对象的 aspx 页面 Test.aspx Select Top 1 * from TestTable。SqlReader 返回后，连接关闭。（我相信 ASP.NET 仍将使用连接池）。假设该页面同时被 500 个用户点击。

这是否意味着 500 个并发连接或 1 个连接，因为我将使用池连接？

PS 我也在寻找 SQL Federations 来扩展数据库层，但是如果每个 DB 允许多达 180 个并发连接并且我查询每个 DB 并为应用程序层上的每个同时用户扇出结果，那么我看不到我是如何扩大规模的。

在 SQL Management Studio 中，当连接到 Azure db 时，您可以展开“Federations”文件夹并获取所有联合数据库的列表。我试图找出可以找到该信息的支持查询，但我的成功非常有限。

谁能指点我一张可能有该信息的桌子？

的背景：

我们有一个主要实体是客户的应用程序。此应用程序中的所有信息都从客户开始。我们认为如果我们可以将它用于某种分区，那就太好了。我们以 Azure SQL 数据库为后端设计了该服务。

我们的表格看起来像这样（为简洁起见，只留下相关部分）：

现在这让我们可以做一些疯狂的事情。我们指向所有 SQL 相关内容的入口总是首先包含以下命令：

在这种情况下，此语句：

或者

将毫无问题地工作，只处理给定客户的数据。CustomerId COLUMN 将始终从系统函数 FEDERATION_FILTERING_VALUE 中推断出来；

现在我们可以毫无问题地将所有客户都放在一个数据库中，并且他们将彼此隔离。如果在未来的某个时候，其中一个变得太大，我们可以在该特定客户 ID 处拆分联合，并且我们不必更改代码中的任何内容来支持它。

哎呀，我们可以让每个客户都在单独的联合数据库中，而使用它的服务对它一无所知。

我们对我们的解决方案非常满意，我认为我很聪明地想出了它。直到最近，微软才宣布他们将弃用 azure federations 功能以及即将推出的新 azure 数据库版本。在此处和此处阅读有关它的更多信息。

我希望你能看到我的问题。你认为我的替代方案是什么？您是否使用 Azure 联合以及您将如何过渡？

谢谢你。