What encryption/decryption method should I use when multiple users should have access to the encrypted information? Ok, I am in a little bit of cryptographical fix :D

I need to figure out a way to encrypt and decrypt data handled by a website. 
The website is intended only for a certain group of people who will use it to upload and search sensitive information.

Data is entered by them using a browser, which should be encrypted before sending and storing it in the server/database.

On the other hand when these users search for a value (say, account number) in the database, it is queried whether present in the database and if yes, it is decrypted and displayed on the browser.

The whole point of encryption/decryption is to make sure that website hosters, owners and administrators do not understand the data values.

It is a website that has multiple users who might be accessing the same data/values from the same database. If we have 1000 registered users, the information uploaded by each of them should be available to all of the 1000 users.

The problem here is that this is not a person to person encryption/decryption (like sending an encrypted email), therefore I am not sure if the private and public key cryptography can be implemented in it's raw form. What is the logical way to implement cryptography in this situation?
Here's an example scheme that should work with $\mathcal O(r)$ operations for $r$ registrations and $\mathcal O(n+r)$ operations for $n$ documents and $r$ revoked (simultaneously) user accounts, but of course would perform all (eg search) operations client-side. This also involves only $\mathcal O(n+r)$ keys. Doing something like this (securely, partially) server-side is possible but more complex, this is called searchable or structured encryption and allows you to eg search for specific keywords / tags without the server learning the precise keyswords. This is eg deployed by pixek (RWC 2018 slides PDF) where apparently these three schemes are used: One, Two, Three.

The initial setup goes like this:


Define a (random) symmetric key $K$ for the entire database.
Define a (random) symmetric key $K_i$ for the $i$-th document.
Encrypt the $i$-th document using $K_i$ and store $\operatorname{Enc}_K(K_i)$ "next to the document" ie so that you can find this ciphertext when you know which document to access.


The per-user registration goes like this:


Encrypt $K$ under a user-specific public key. This is what happens upon registration. This public key may be stored symmetrically encrypted on the server using the user's password.


Revokation then works like this:


Upon revokation pick a new $K'$. Re-encrypt all $K_i$ with that $K'$ and encrypt the new $K'$ under the public keys of all the users and replace the old encryptions of $K$.


Accessing a document then goes like this:


The user retrieves their private-public keypair.
The user requests their encrypted copy of $K$ and decrypts it.
The user requests a document with its encrypted per-document key, decrypts this key and decrypts the document.


Because this question will probably come up: 


  Why not use the global key to encrypt all the documents directly?


The idea is to a) limit the amount of ciphertext available under a single key and b) that if some user has access, they learn $K$, and so you would have to actually re-encrypt all the documents after their access gets revoked in case an admin leaks the ciphertext blobs. If you also update the per-document key on each document update any user will only be able to decrypt documents they have already seen this way.