Context:
I am using trial version of Enterprise Edition of Snowflake;
1) Created a database and table with some data and warehouse COMPUTE_WH
2) created reader account and shared table to that reader account and warehouse to use as data consumer : TEST_WH
when i see as an Account admin logged in as in step1; i see two warehouses; count but displays only one warehouse and the same when i login as data consumer dispays 2 warehouses and dispays "TEST_WH"
in sceanrio :
1) I am provider of the data and data sharing to another reader account and created warehouse for the data consumer;
I want to track how much Provider account warehoused used and also how much data consumers are spending credits;
There are 2 issues here :
- Why the data consumer account displays two warehouses but as per that account it is only 1 warehouse being created and used;
- Data Provider account says two warehouses but does not display warehouse "test_wh" credits usage.
Has any observed this?
It is not clear how you can create a warehouse and share it with the consumer account. The Consumer account admin needs to create a warehouse and use it for data processing requests.
Can you kindly update this space with the steps that you performed in sharing the warehouse from the provider account?
In general, the virtual warehouses created by the consumer ma consume credits, which will be charged to your provider account. If you wish to control the amount of credits consumed monthly by the virtual warehouses in the reader account you can use the resource monitor to configure.
Ref : https://docs.snowflake.com/en/user-guide/data-sharing-reader-config.html#task-4-create-resource-monitors-optional
Related
How do we find which partner tools is consuming most credits in snowflake.
I can get most credits results for drivers(JDBC,ODBC),but i need to find for tools like power bi etc.
Credits are consumed for a duration warehouse is active, not by any drivers or tools.
More details: https://docs.snowflake.com/en/user-guide/credits.html#virtual-warehouse-credit-usage
Users with the ACCOUNTADMIN role can use the Snowflake web interface or SQL to view monthly and daily credit usage for all the warehouses in your account.
https://docs.snowflake.com/en/user-guide/credits.html#viewing-warehouse-credit-usage-for-your-account
In snowflake share Data Providers can share data with only the Data Consumer and does Snowflake charges additional fees to Data providers for each share they create?
Also is it possible that after sharing the Data Consumer can extend that data shared to them to other Data Consumers?
does Snowflake charges additional fees to Data providers for each share they create?
No, there is no additional charge. This is because, when you share data, no actual data is copied, so there is no additional storage required and therefore no associated additional cost. Even the process of creating the share and granting privileges for databases and other supported database objects (schemas, UDFs, tables, and views) to a share does not incur any direct cost since these are metadata operations and are thus part of Cloud Services. Snowflake credits are used to pay for the usage of the cloud services that exceeds 10% of the daily usage of the compute resources. Usage for cloud services is charged only if the daily consumption of cloud services exceeds 10% of the daily usage of the compute resources.
If data is shared outside the region where the Snowflake account is hosted then will be additional storage costs for replication.
is it possible that after sharing the Data Consumer can extend that data shared to them to other Data Consumers?
It is not possible to share a consumed share.
The reader account can be used to share the data with users, where they can only run SELECT queries. How is it different than a user who is having a role with read-only access? What purpose does a reader account serve with a reader account?
Primarily, the Reader account purpose is to provide read-only data using shares to consumers, hence it is named reader account.
Reader account is not restricted by the conventional RBAC read-only privileges. You may create new users and grant any priviligies but the data that is being shared by the provider would be only read-only.
Reader account is one of the use cases for the Secure Data Sharing feature.
Details for all use cases: https://docs.snowflake.com/en/user-guide/data-share-providers.html
Reader accounts enable providers to share data with consumers who are not already Snowflake customers, without requiring the consumers to become Snowflake customers.
A reader account enables data consumers to access and query data shared by the provider of the account, with no setup or usage costs for the consumer, and no requirements for the consumer to sign a licensing agreement with Snowflake.
The reader account is created, owned, and managed by the provider account, which assumes all responsibility for credit charges incurred by users in the reader account. Similar to standard consumer accounts, the provider account uses shares to share databases with reader accounts; however, a reader account can only consume data from the provider account.
Details: https://docs.snowflake.com/en/user-guide/data-sharing-reader-create.html
Reader account is for users/consumers who are not on Snowflake. Reader account helps to keep the workload and management separate from your main account.
If you are a data provider, and you would like to share the data with one of your colleagues, for example, you would create a user for them in your main account. However, if you are a data provider, and would like to share the data with users outside your organization, that are not currently signed up for Snowflake, you will create a reader account for them, and share the data with that reader account.
In the latter case, the data consumers can then further manage the user management in the reader account, without you, as a data provider, having to do so.
Reader accounts are very handy in testing scenarios, where you would like to keep the testing completely separate from your actual (main) account, or, when you want to share data with consumers who do not want to sign up for Snowflake and handle billing.
Our organization is looking to bring on board the Alation product for data mining.
To do so, Alation requires a service account in Snowflake to touch every database, every schema in Snowflake.
Obviously this is very broad access and the org is concerned about security.
Has anyone else done this, and possibly quantify the risks involved?
I’m looking at an implement for multi-tenancy in SQL Server. I'm considering a shared database, shared schema and tenant view filter described here. The only drawback is a fragmented connection pool...
Per http://msdn.microsoft.com/en-au/architecture/aa479086, Tenant View Filter is described as follows:
"SQL views can be used to grant individual tenants access to some of the rows in a given table, while preventing them from accessing other rows.
In SQL, a view is a virtual table defined by the results of a SELECT query. The resulting view can then be queried and used in stored procedures as if it were an actual database table. For example, the following SQL statement creates a view of a table called Employees, which has been filtered so that only the rows belonging to a single tenant are visible:
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()
This statement obtains the security identifier (SID) of the user account accessing the database (which, you'll recall, is an account belonging to the tenant, not the end user) and uses it to determine which rows should be included in the view"
Thinking this through , if we have one database storing say 5,000 different tenants, then the connection pool is completely fragmented and every time a request is sent to the database ADO.NET needs to establish a new connection and authenticate (remember connection pooling works for each unique connection string) and this approach means you have 5,000 connection strings…
How worried should I be about this? Can someone give me some real world examples of how significant an impact the connection pool has on a busy multi-tenant database server (say servicing 100 requests per second)? Can I just throw more hardware at the problem and it goes away?
Thoughts ??
My sugestion will be to develop a solid API over your database. Scalability, modularity, extensibility, accounting will be the main reasons. Few years down the line you may be found swearing at yourself for playing with SUSER_SID(). For instance, consider multiple tenants managed by one account or situations like whitelabels...
Have a data access api, which will take care of authentication. You can still do authorisation on the DB level, but it's a whole different topic then. Have users and perhaps groups and grant them permissions to tenants.
For huge projects nevertheless, you'll still find it better to have a single DB per big player.
I see I did not answer your main question about fragmented connection pool performance, but I'm convinced there are many valid arguments not to go that path nevertheless.
See http://msdn.microsoft.com/en-us/library/bb669058.aspx for hybrid solution.
See Row level security in SQL Server 2012