PHP Filesystem JSON Files DB
The only good thing about this code is your desire to invent. It is a very good desire, only ones possessing it make good programmers. You just made the very first step towards inventing your own database, just like every aspiring newbie programmer does. And that's a very good sign per se.

Everything else about this code - let me be frank - is bad. From the main idea to the minute syntax issues. To outline some misconceptions:


The premise. I know, I know, you have a million reasons not to use a relational database. All of them are wrong though. Beside an aspiration, a good programmer possesses a thing called common sense. Which is bound to tell them that generations of programmers created and polished a thing called a relational database for a reason.
the above leads to the number of consequences:


scalability. By no means it is good for any project you would call "large". All these manual loops in the memory will become unbearably slow. A good database never loads the entire file in the memory, it reads a file by chunks. And uses indexes to speed up all the operations dramatically.
race condition. With your database you will learn the hard way such things like file locking and a race condition. In concurrent environments a file must be locked when operated with, in order to prevent other files from accessing it. Or it will lead to data corruption and other unwanted consequences.
features. SQL is one of the greatest inventions of the last century. In a relatively short sentence that is close to natural English it lets us to do the data filtering, ordering, aggregation. How many lines of code you will have to write to get the overall salary for all employees? Grouped by departments? For the certain period? It's just a single line in SQL mind you.  

naming. What do remove(), delete() and destroy() functions do? Can you tell from looking at them used in the code? 
OOP. Not to mention the ancient constructor definition (it was discouraged from using for decades!), the overall class structure is flat. It's just a collection of functions. There is no delegation, no abstraction, no separation of concerns. At least there should be two classes, one operating at the filesystem level and one operating at the single json file level.
syntax in general. Again, it seems to be inevitable for many people to pass such a stage, trying to make a code easier to write, making names gibberish as a result. It takes time to realize that reading is much more important than writing, and such names as p(), $d and such is a blasphemy. Every variable and method should have a meaningful name.
if (count($r) == 1) return $r[0]; is my favorite. I learned the hard way that such a magic will lead to a situation when your code expects a 2-dimensional array of rows but gets just a single row. It's funny to see the result when you are trying to loop over it and then access distinct fields inside each element. there must be explicit methods to get you certain result types, you want to look at PDOStatement for inspiration
error reporting. at least for json_encode() you have to implement a wrapper that will produce a meaningful error message

function jsonDecode($json, $assoc = false)
{
    $ret = json_decode($json, $assoc);
    if ($error = json_last_error())
    {
        throw new Exception(json_last_error_msg(), $error);
    }
    return $ret;
}